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Process-Centered  Development  Environments: 
An  Exploration  of  Issues 

Abstract:  Software  development  environments  are  beginning  to  move  from 
research  communities  to  commercial  applications.  As  this  occurs,  the  need  to 
address  process  issues  related  to  such  environments  is  becoming  increasingly 
apparent.  Thus  there  is  a  growing  awareness  of  the  need  for  process-centered 
development  environments  (PCDEs).  This  report  addresses  process  definition 
and  enactment  issues  which  pertain  to  the  specification  and  design  of  a  PCDE. 
The  first  part  of  the  report  explores  some  of  the  required  characteristics  of  an 
enactable  graphical  language  and  the  relationship  between  process  definition 
and  enactment.  This  process  language  naturally  led  to  the  ability  to  perform 
process  verification,  i.e.,  a  verification  that  the  actual  process  path  taken 
throughout  a  project  conforms  to  the  defined  process.  The  issue  of  process 
verification  is  thus  also  explored.  The  success  of  PCDE*  rests  heavily  on  end- 
user  acceptance.  Because  of  this,  the  report  concludes  with  a  review  of  user- 
oriented  process  and  social  issues  relevant  to  the  successful  adoption  of 
PCDEs. 


1  Background 

Software  production  has  historically  been  a  very  iabor-intensive,  highly-skilled  and  costly  busi¬ 
ness.  In  addition,  the  more  technically  advanced  Western  nations  have  led  the  way  in  the  rap¬ 
idly  changing  field  of  software  engineering.  However,  other  nations,  whose  labor  costs  are  far 
below  those  of  the  West,  are  catching  up  [Firth  9&J.  These  facts,  coupled  with  the  efficiency  ot 
global  communications,  suggests  that  the  competitive  position  of  Western  nations  in  software 
development  may  soon  erode.  Software  is  a  strategic  technology,  from  both  defense  and  com¬ 
mercial  points  of  view,  and  loss  of  this  competitive  edge  could  have  profound  consequences. 

How  can  this  competitive  edge  be  maintained?  Several  elements  are  necessary.  First,  a  vi¬ 
brant  infrastructure  (such  as  Silicon  Valley)  where  intense  competition  drives  technology 
ahead  of  outside  competition  is  needed.  Second,  an  educated  workforce,  capable  of  using 
new  technologies  and  of  rapidly  adapting  to  new  circumstances,  must  be  available.  Third,  an 
emphasis  on  continuously  improving  software  quality  and  hence  organizational  performance 
is  required.  Since  the  process  with  which  a  product  is  built  has  a  direct  bearing  on  quality,  an 
understanding  of  the  process  is  essential.  Finally,  once  a  well-defined  process  has  been  de¬ 
veloped.  the  process  may  be  automated  as  a  means  of  assuring  process  consistency  and  of 
reducing  cost.  Automation  of  the  process  includes,  but  is  not  limited  to,  providing  software  or¬ 
ganizations  with  appropriate  tools  to  perform  specific  tasks,  relieving  developers  and  manag¬ 
ers  of  as  much  tedium  as  possible,  eliminating  error-prone  activities,  and  guiding  process- 
critical  tasks.  Such  support  should  allow  developers  and  managers  to  concentrate  on  creative 
non-automatable  tasks.  If  such  cost-reducing,  quality-enhancing  measures  are  not  taken,  the 
competitive  advantage  currently  held  by  those  countries  that  have  relatively  high  labor  rates 
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is  likely  to  disappear.  One  such  cost-reducing,  quality-enhancing  measure  is  to  introduce  pro¬ 
cess-centered  development  environments  (PCDEs). 

A  note  of  caution  should,  however,  be  observed  with  respect  to  automating  software  produc¬ 
tion.  When  producing  mechanical  or  electrical  produce,  the  number  of  component  variants  is 
usually  fewer  than  the  number  of  software  variants,  logical  complexity  is  less,  and  initial  re¬ 
quirements  are  usually  better  understood  than  with  software  products.  These  factors  often  re¬ 
sult  in  mechanical  and  electrical  products  having  logically  simpler  manufacturing  processes. 
As  a  result,  while  much  of  hardware  manufacturing  can  be  performed  repetitively  by  machines, 
software  production,  having  a  higher  intellectual  (and  non-standardized)  content,  tends  to  be 
manually  produced.  Thus  any  approach  to  software  automation  cannot  simply  rely  on  princi¬ 
ples  developed  for  hardware.  In  particular,  software  automation  forces  a  very  tight  and  com¬ 
plex  relationship  between  the  computer  environment  and  the  software  developer. 
Consequently,  an  understanding  of  human-computer  interaction  >s  particularly  important  for 
PCDEs  to  be  effective.  Simply  automating  the  software  production  process  without  giving  due 
importance  to  end-user,  process  and  even  social  issues  could  result  in  the  erroneous  conclu¬ 
sion  that  automation  does  not  work. 
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2  A  Process  Development  and  Usage  Scenario 

This  report  addresses  issues  relevant  to  improving  the  software  productivity  and  quality,  as 
they  relate  to  PCDEs.  First,  it  emphasizes  that  both  technology  and  user  issues  affect  suc¬ 
cess.  Second,  it  suggests  that  a  graphical  and  enactabie  specification  of  the  PCDE  will  con¬ 
tribute  significantly  to  the  successful  implementation  of  the  PCDE.  Third,  it  discusses  process 
verification.  Process  verification  affects  quality  because  it  guarantees  compliance  with  the  de¬ 
fined  process. 

Figure  2-1  illustrates  a  proposed  process  development  and  usage  scenario.1  This  figure  sum- 

Step 


Figure  2-1  The  Process  Development  and  Usage  Scenario 


marizes  the  technical  steps  necessary  to  implement  a  PCDE.  The  first  step  in  Figure  2-1  de¬ 
fines  an  appropriate  process  model  with  which  to  support  the  software  development  activity. 


1  In  the  following  text,  the  numbers  down  the  right  hand  side  of  Figure  2-1  are  referred  to  as 
steps. 
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The  process  supported  could  be  a  modest  one  such  as  peer  reviews  or  it  could  be  a  wide- 
ranging  one  such  as  comprehensive  project  support.  In  any  case,  this  process  is  defined  using 
a  graphical  language.  In  Step  2,  the  graphical  model  is  compiled  into  a  symbolic  and  execut¬ 
able  form.  Through  this  executable  form,  the  dynamics  of  the  process  can  be  studied  at  a  high 
level,  without  being  encumbered  at  this  point  by  the  low-level  implementationa!  detail.  Validat¬ 
ing  the  model  (Step  3)  will  likely  involve  logical  (static)  analysis  to  check  for  deadlock  and 
reachability  and  dynamic  simulation  to  test  the  system's  behavioral  characteristics.  After  the 
model  has  been  formally  validated,  managers  and  developers  will  be  asked  to  agree  upon  its 
adequacy  from  a  user  perspective.  This  buy-in  of  managers  and  developers  is  essential  if  the 
process  is  to  gain  acceptance.  By  defining  the  model  graphically,  communication  and  agree¬ 
ment  on  the  process  model  will  be  significantly  enhanced.  Such  a  visible  representation  is 
more  readily  comprehensible  than  a  process  defined  through  text  or  symbolic  coding.  In  addi¬ 
tion,  modifying  the  defined  process  at  this  point  is  less  expensive  than  to  waiting  until  major 
development  of  the  actual  PCDE  has  been  performed. 

Steps  1  through  4  are  analogous  to  the  process  through  which  the  specification  of  a  software 
product  is  developed  using  graphical  techniques.  As  stated  in  [Osterweil  87]: 

Because  software  processes  are  programs  in  what  we  now  see  as  to  be  the  classical 
sense  of  the  term,  we  should  expect  that  they  are  best  thought  of  as  being  only  part  of 
a  larger  information  aggregate.  This  information  aggregate  contains  such  other  soft¬ 
ware  objects  as  requirements  specifications  (for  the  process  description  itself)... 

This  is  indeed  what  we  are  doing  by  defining  the  process  specification  in  Step  5.  However, 
[Oserweil  87]  also  states  that  'the  process  itself  is  adynamic  entity  and  the  process  description 
is  a  static  entity." 

As  we  have  seen  above,  our  specification  is  also  dynamic.  This  allows  us  not  only  to  be  precise 
and  formally  consistent  in  a  static  sense,  but  also  to  be  more  behaviorally  correct.  By  allowing 
for  behavior  in  the  specification,  we  can  address,  in  a  preliminary  way,  some  basic  end-user 
issues  prior  to  investing  in  the  full-scale  implementation.  At  this  point,  the  enactable  specifica¬ 
tion  defines  all  significant  high-level  artifacts  in  the  process,  the  agents  or  roles  who  will  per¬ 
form  the  activities,  and  the  decisions  which  are  made  or  acted  upon  throughout  the  process. 

The  architecture  or  implementation  of  the  PCDE  that  occurs  in  Step  6  could  take  many  forms. 
At  one  end  of  the  spectrum,  tools  can  be  directly  coupled  to  allow  for  simple  process  enact¬ 
ment  (point-to-point  integration).  More  complex  process  enactment  is  also  possible,  for  exam¬ 
ple,  using  an  underlying  framework  which  provides  control  and  data  integration  mechanisms 
for  coupling  diverse  tools  [Wallnau  91].  Recently,  a  number  of  commercial  process  support 
and  enactment  tools  have  become  available;  these  are  in  addition  to  those  which  have  aca¬ 
demic  origins.  Such  process  support  tools  may  prove  to  be  critical  to  finding  a  total  PCDE  so¬ 
lution.  However,  they  are  not  the  main  subject  of  this  report. 

Collecting  process  metrics  is  essential  to  process  understanding  and  improvement.  Having  a 
defined  model  of  one’s  process  significantly  simplifies  the  selection  of  which  metrics  to  gather 
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(Step  7).  These  metrics  are  gathered  during  the  software  product’s  manufacture.  Such  metrics 
may  include  decisions  taken,  intermediate  product  versions  used,  reviews  completed,  and 
which  agents  involved  in  each  of  the  activities  (Step  8).  Upon  completion  of  the  project,  these 
metrics  can  also  be  used  to  verify  that  the  as-implemented  process  conforms  to  the  as-defined 
process  (Step  9).  Note  that  in  Step  3  we  have  used  “validate"  to  imply  correctness  of  the  en¬ 
acted  process  model,  while  in  Step  7  we  have  used  the  word  “verify”  to  mean  compliance  of 
the  is-implemented  process  with  the  as-defined  process.  This  convention  will  be  used  through¬ 
out  the  rest  of  the  report. 

This  report  focuses  on  Steps  1 , 2,  and  9  which  are  discussed  in  Sections  3, 4,  and  5  respec¬ 
tively.  These  three  areas;  process  definition,  enactment,  and  verification  can  all  rely  on  the 
same  graphical  notation,  independent  of  the  specific  PCDE  used  for  implementation;  hence  it 
makes  sense  to  discuss  them  under  the  common  heading  of  this  report.  Section  3  describes 
the  graphical  language  ProNet,  which  was  explicitly  developed  for  process  modeling  with  en¬ 
actment  in  mind.  Section  4  discusses  how  models  within  this  language  can  be  translated  into 
an  enactable  form.  Section  5  then  explains  how  verification  can  be  performed  using  the  same 
ProNet  notation,  together  with  process  data  gathered  during  product  development.  Finally, 
Section  6  reviews  some  general  issues  associated  with  end-user  needs,  organizational  fac¬ 
tors,  and  process  automation  in  light  of  Hie  process  modeling  experience.  Such  issues  as  what 
can  and  should  be  automated,  environment  support  versus  control,  and  developer  needs  ver¬ 
sus  management  needs  are  discussed. 

Implementation  issues  associated  with  PCDEs  will  not  be  addressed.  Thus  we  will  not  inves¬ 
tigate  what  tools  are  needed  to  support  software  development,  how  these  tools  are  integrated, 
or  what  use  is  made  of  environment  frameworks.  In  summary,  it  is  intended  that  the  following 
work  form  a  basis  for 

•  exploring  issues  associated  with  process  definition  and  enactment  in  the 
context  of  process  model  specification  and  validation, 

•  addressing  the  issue  of  software  quality  through  process  verification,  and 

•  investigating  end-user  issues  with  respect  to  process  automation. 

It  is  intended  that  process  models  defined,  enacted,  and  evaluated  using  the  techniques  de¬ 
scribed  in  this  report  will  actually  be  implemented  through  recently  available  process  support 
tools  such  as  SynerVision  [Cooley  92],  ProcessWeaver  [Ellen  92],  or  ProcessWise  [Bruy- 
nooghe  91  ].  These  investigations  will  be  the  subject  of  another  report. 
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3  The  ProNet  Graphical  Modeling  Language 

This  section  discusses  the  graphical  modeling  language  ProNet  (Step  1  in  Figure  2-1)  which 
forms  a  basis  for  process  enaction.  Section  3.1  first  discusses  why  there  should  be  dose  re¬ 
lationship  between  graphical  process  definition  and  process  enactment.  The  ProNet  notation 
itself  is  described  in  some  detail  in  Section  3.2,  while  Section  3.3  compares  this  notation  to 
that  of  several  other  well-known  modeling  approaches.  Finally,  Section  3.4  illustrates  the  no¬ 
tation  with  a  small  process  modeling  example. 

One  general  definition  of  process  is:  A  set  of  partially  ordered  steps  intended  to  reach  a  goal 
[Feiler  92].  Given  this  definition,  steps,  which  are  interpreted  to  be  activities,  take  a  central 
position  in  ProNet.  An  activity  may  only  occur  if  certain  entrance  conditions  are  met  or  if  certain 
products  become  available.  As  a  consequence  of  the  activity,  exit  conditions  may  change  from 
false  to  true  (or  vice  versa)  and  certain  products  may  be  generated.  Hence  the  firing  of  an 
activity  changes  the  state  of  the  system,  generating  and  setting  up  necessary  entrance 
conditions  for  other  activities  to  fire.  ProNet  is  thus  a  dedarative  model.  Each  activity  and  its 
entrance  and  exit  conditions  bear  a  strong  relationship  to  the  elements  of  a  rule  in  a  rule-based 
system,  it  is  because  of  this  characteristic  that  enactability  is  possible. 

3.1  The  Relationship  Between  Process  Definition  and  Enactment 

Why  develop  a  graphical  process  notation  with  enactable  characteristics?  There  are  many  val¬ 
id  reasons  for  doing  so: 

•  Debugging  an  enactable  process  can  be  significantly  easier  if  a  graphical 
form  of  the  process  model  is  used.  Automatic  transformation  of  the  graphical 
model  to  its  enactable  form  then  guarantees  a  degree  of  correctness  not 
found  when  the  model  is  developed  analytically. 

•  By  having  enactable  characteristics,  a  process  model  can  be  used  to  explore 
different  process  alternatives  before  any  process  is  implemented.  By 
providing  a  debugged,  enactable,  and  agreed- to  process  model,  the 
simulated  process  can  be  faithfully  reproduced  in  the  real  world.  This  has 
implications  not  only  for  establishing  the  initial  process  but  for  process 
modification  and  improvement. 

•  Both  the  graphical  model  and  its  enactable  form  will  provide  guidance  on  tool 
integration  issues.  The  process  model  specifies  the  input  and  output  data 
and  control  information  (through  the  products  and  conditions),  thus  providing 
a  rational  basis  for  communication  between  tools.  (Of  course,  actual 
integration  of  the  tools  within  a  process  support  environment  raises  many 
implementation  issues  not  addressed  in  this  report.) 
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•  There  are  significant  advantages  to  defining  the  process  graphically, 
independent  of  enactability  considerations: 


-  Graphical  specification  provides  a  means  to  communicate  to  develop¬ 
ers,  management  and  others  what  the  “new”  process  will  look  like.  This 
generates  early  feedback  from  those  involved  in  the  future  use  of  the 
process,  thus  encouraging  its  success. 

-  Managers  can  thus  sign-off  on  a  defined  process  without  having  to  un¬ 
derstand  a  complex  symbolic  notation. 

-  The  graphical  process  model  allows  for  accelerating  training  for  new 
employees. 

•  If  incorporated  into  a  PCDE,  the  graphical  model  can  be  used  for  real-time 
process  support,  as  a  “front-end”  for  task  selection  and  to  obtain  process- 
related  status  information  during  product  development. 

The  ProNet  graphical  process  notation  can  readily  be  mapped  to  a  set  of  production  rules 
through  which  the  process  can  be  enacted.  The  resulting  symbolic  model  can  then  be  used  to 
investigate  the  dynamic  characteristics  of  the  process  or,  equally  importantly  in  our  case,  to 
define  the  characteristics  of  a  process  driver  for  a  PCDE. 

3.2  Entity  Classes 

This  section  provides  a  definition  of  the  notation.  ProNet  diagrams  are  based  on  a  modified 
Entity-Relation  model  [Chen  83]  in  which  entities  fall  into  one  of  eight  classes.  The  following 
list  defines  these  entity  classes: 

•  Activities  provide  the  backbone  to  the  process  model.  Other  entity  classes  are 
attached  to  and  support  activities.  The  existence  of  products  and  conditions  (which 
are  defined  below)  provide  the  entrance  conditions  for  activity  initiation.  Activities  are 
responsible  for  generating  exit  products  and  conditions. 

•  Products  can  either  be  required  to  support  an  activity  or  be  produced  by  an  activity. 

Products  may  be  the  result  of  some  activity  internal  to  the  model  (e.g.  a  file 
containing  source  code)  or  maybe  generated  outside  of  it. 

•  Conditions  can  either  be  required  to  initiate  an  activity  or  result  from  an  activity  (e  g., 

“review  completed")  and  take  the  values  TRUE  or  FALSE.  The  existence  or  non¬ 
existence  of  a  product,  agent,  etc.,  can  be  equivalent  to  a  condition. 

•  Composites  are  boolean  combinations  of  conditions,  products,  agents,  etc. 
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•  Agents  are  specific  entities  which  perform  activities.  Humans  or  non-human  entities 
capable  of  performing  activities  (e.g.,  the  software  developer,  Mary  or  the  Vertex  C 
Compiler,  Ver  5.0)  are  considered  to  be  agents.  Agents  may  support  activities  or  may 
be  derived  from,  or  identified  by,  activities. 

•  Roles  are  abstractions  (i.e.,  a  super-class)  of  the  agents  concept  (e.g.,  reviewer, 
editor).  If  the  process  model  is  enactable,  the  role  must  be  instantiated  by  an  agent 
at  run  time.  Like  agents,  roles  may  support  multiple  activities  or  may  be  derived  from, 
or  identified  by,  activities. 

•  Stores  allow  for  persistence  of  instantiated  entities.  Products,  condition  values  and 
even  agents  can  be  deposited  in  or  retrieved  from  stores. 

•  Constraints  are  policy  restrictions  imposed  on  the  performance  of  an  activity.  Unlike 
conditions  these  do  not  take  on  boolean  values  but  may  reflect  guidance  on  how 
things  are  done  (e.g.,  a  quality  assurance  constraint  such  as  on  documenting  written 
code). 

Most  relationships  link  the  entities  to  the  activities.  These  relationships  types  are  of  the  form 
shown  in  Tables  1  and  2. 


Table  1  Entrance  Relationships 


Entrance  relationships 

Inverse  entrance  relations 

productA  is  entrance  product  for  activity _A 

activity_A  has  entrance  product  product  A 

condilion  A  is  entrance  condition  for  activity _A 

activity_A  has  entrance  condition  condition_A 

compositeA  <s  entrance  composite  for  activity _A 

activityA  has  entrance  composite  compos  iteA 

agerrtA  is  entrance  agent  for  activity _A 

activity_A  has  entrance  agent  agerttA 

role_A  is  entrance  role  for  activity _A 

activity _A  has  entrance  role  role_A 

storeA  is  entrance  store  for  activity_A 

activity _A  has  entrance  store  store_A 

Table  2  Exit  Relationships 


Exit  relationships 

Inverse  exit  relations 

product_A  is  exit  product  for  activity _A 

activity_A  has  exit  product  product_A 

condition  A  is  exit  condition  for  activity _A 

activity_A  has  exit  condition  condition_A 

compositeA  is  exit  composite  for  activity _A 

activityA  has  exit  composite  composite  A 

agent_A  is  exit  agent  foractivity_A 

activity_A  has  exit  agent  agent_A 

role_A  is  exit  role  for  activity _A 

activity_A  has  exit  role  role_A 

store_A  is  exit  store  for  activity _A 

activity _A  has  exit  store  store_A 

In  the  process  diagrams,  these  relationships  are  all  written  in  italics.  The  information  they  con¬ 
tain  allows  the  reader  to  identify  the  class  of  entity  which  is  linked  to  the  activity.  Also,  if  a  re- 
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lationship  (such  as  “product_A  is  entrance  product  for  activity_A")  holds,  so  does  the  inverse 
relationship  (“activity_A  has  entrance  product  product_A") . 

In  the  process  diagrams,  activities  can  be  identified  since  they  always  have  a  shadowed  box 
around  the  entity  name.  In  addition,  a  black  dot  is  placed  next  to  the  entity  at  the  end  of  the 
relationship.  For  example,  in  the  relationship  “ABC  is  entrance  product  forXYZ’,  the  dot  would 
appear  in  the  graphical  relationship  close  to  the  box  surrounding  the  activity  XYZ.  Thus  the  dot 
plays  the  same  role  as  the  tip  of  an  arrow  does  in  entity-relationship  diagrams.  The  final  entity 
class,  the  constraint,  is  simply  imposed  on  an  activity,  rather  than  being  attached  to  the  initia¬ 
tion  or  conclusion  of  an  activity.  Thus,  a  constraint's  relationships  to  an  activity  are  of  the 
forms: 


•  constraint_A  is  constraint  for  activity_A 

•  activity__A  has  constraint  constraint_A 

ProNet  handles  three  other  relationship  types:  inheritance,  aggregation,  and  custom.  With 
respect  to  inheritance,  there  are  two  named  relationships:  is  instance  of  and  is  generalization 
of,  each  of  which  is  the  inverse  of  the  other.  Unlike  the  relationships  discussed  earlier,  these 
relationships  link  two  arbitrary  entities,  so  long  as  they  are  of  the  same  class.  With  respect  to 
aggregation,  there  are  also  two  named  relationships:  is  part  of  and  includes,  each  of  which  is 
the  inverse  of  the  other.  These  also  link  arbitrary  entities  together,  but  there  is  no  constraint 
that  the  joined  entities  be  of  the  same  class.  Occasionally  there  is  a  need  to  define  a  non¬ 
standard  relationship  between  two  entities  which  does  not  fall  into  one  of  the  predefined 
categories.  ProNet  allows  definition  of  a  “custom”  relationship.  This  feature  allows  creation  of 
an  arbitrary  relationship  (i.e.,  one  not  belonging  to  the  pre-defined  set)  to  link  two  entities.  For 
example  one  might  define  the  custom  relationship  depends  on  as  in  the  example: 

agent_A  depends  on  re source_A2 

ProNet  provides  a  second  way  of  substructuring  entities  besides  use  of  the  is  part  of 
relationship.  While  the  is  part  of  relationship  allows  the  components  of  an  entity  to  be 
displayed  on  the  same  graph  as  the  entity  itself,  it  is  sometimes  necessary  to  display  the 
detailed  structure  of  an  entity  (particularly  an  activity)  on  a  separate  graph.  Most  real-world 
process  models  have  significant  complexity,  and  this  latter  approach  allows  for  multiple-levels 
of  hierarchical  decomposition.  If  a  particular  entity  in  a  process  diagram  has  an  underlying 
structure,  then  the  box  representing  that  entity  is  enlarged  so  as  to  be  twice  as  deep  as  the 
normal  entity  box. 


2  Because  custom  relationships  are  not  defined  within  the  standard  set  of  relationships  types, 
they  weaken  the  formalism.  This  option  thus  cannot  be  used  in  an  enactable  form  of  the  mod¬ 
el.  However,  from  the  point  of  view  of  describing  process,  as  opposed  to  its  enaction,  custom 
relationships  can  be  useful  if  used  with  discretion. 
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3.2.1  Basic  Graphical  Elements 

As  previously  stated,  the  notion  of  activity  is  central.  Generally  the  goal  of  the  software  process 
is  to  produce  software  products.  Thus,  one  outcome  of  activities  is  to  produce  products. 
Another  activity  is  making  decisions,  the  outcomes  of  which  are  reflected  in  the  values 
attached  to  conditions.  Also  activities  cannot  generally  begin  unless  certain  products  and 
agents  are  available  and  certain  conditions  are  satisfied.  This  view  can  be  represented  as 
shown  in  Figure  3-1 . 


Figure  3-1  Basic  Representation  of  a  Process  Element 


Note  the  following  about  this  representation: 

•  It  is  an  entity-relationship  diagram,  with  the  entity  classes  activity,  product, 
condition,  agent,  rote,  junction,  and  constraint  being  defined  within  the 
notation. 

•  As  shown  in  Tables  1  and  2,  relationships  have  predefined  types.  In  the 
above  diagram,  is  entrance  condition  for  and  is  exit  condition  for  relate 
conditions  to  activities.  Similar  relationships  exist  for  products.  Inverse 
relationships  always  hold. 

Other  entities  must  also  support  the  notion  of  activity.  At  least  one  agent  or  role  must  be  as¬ 
sociated  with  any  activity.  A  role  represents  an  abstraction  of  an  agent.  For  example  manager 
is  an  example  of  a  role  while  Joe  is  an  example  of  an  agent  that  may  take  on  the  attributes  of 
a  manager.  The  agent  concept  is  thus  a  subclass  of,  and  takes  on  the  properties  of,  the  role 
concept. 

Agents  and  roles  may  or  may  not  be  human.  Examples  of  non-human  roles  are  compilers  and 
editors.  Agents  not  only  support  activities  (through  the  relationship  is  entrance  agent  foi ),  but 
may  be  identified  by,  or  generated  by,  an  activity.  Generally  human  agents  are  “identified" 
while  non-human  agents  are  “generated”.  The  human/non-human  distinction  is  not  as  critical 
for  process  definition  as  it  is  for  enaction.  Thus  ProNet  does  not  explicitly  distinguish  between 
human  and  non-human  agents  and,  for  both  cases,  the  ProNet  relationship  is  is  exit  agent  for. 
The  same  is  true  for  roles.  For  process  enaction,  however,  the  distinction  clearly  is  important 
since  automated  agents  may  initiate  activities  without  human  intervention.  These  additions  are 
shown  in  Figure  3-2. 
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In  defining  an  enactable  process  model,  it  may  be  necessary  to  establish  some  entities  as  role 
since  the  specific  agent  will  not  be  not  known  prior  to  process  enactment.  In  other  cases  the 
agent  may  be  known.  For  example,  it  may  be  known  that  Fred  will  be  manager  of  a  project;  it 
may  not  be  known  which  developer  will  perform  a  specific  technical  task  for  Fred.  Thus  agents 
that  are  explicitly  defined  in  the  process  model  represent  early  bindings  of  roles. 

Two  entity-labeling  conventions  should  also  be  noted.  First,  a  numerical  extension  on  classes 
of  entities  which  are  not  activities  indicates  instances  of  the  same  entity.  For  example,  proj  file 
1  and  proj  file  2  are  different  instances  of  the  same  physical  product,  proj  file.  As  will  be  seen 
later,  this  can  be  convenient  in  defining  the  graphical  process  model.  Such  a  labeling 
convention  is  also  sometimes  necessary  for  reasons  of  uniqueness  during  process 
enactment.  On  the  other  hand,  numerical  extensions  on  activities  do  indicate  truly  different  and 
separate  activities. 

An  important  concept  in  the  basic  notation  is  the  junction  class.  Junctions  allow  boolean 
combinations  of  entities  to  be  logically  related,  either  as  input  to  an  activity  or  as  the  output 
from  an  activity.  There  are  four  instances  of  the  junction  class:  CA,  CO,  DA,  and  DO,  where  C 
stands  for  convergent,  D  stands  for  divergent,  A  stands  for  AND  and  O  stands  for  OR.  Since 
convergent  junctions  are  always  implemented  prior  to  an  activity  they  are  called  entrance 
junctions.  Similarly,  since  divergent  junctions  are  always  implemented  after  an  activity  they  are 
called  exit  junctions.  These  are  described  below: 

•  CA:  This  stands  for  a  convergent  AND  junction.  In  this  kind  of  junction,  an 
example  of  which  is  shown  in  Figure  3-3,  several  entities  must  all  be  present 
before  the  output  from  the  junction  is  activated. 
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•  CO:  This  stands  for  a  convergent  OR  junction  and  is  similar  in  structure  to  the 
CA  junction.  In  this  case,  however,  only  one  branch  of  the  inputs  needs  to  be 
activated  before  the  activity  can  be  fired. 

•  DA:  This  stands  for  a  divergent  AMO  junction.  As  a  result  of  an  activity,  a 
conjunction  of  conditions  and  products  may  result.  While  agents  or 
constraints  may  by  required  as  components  of  an  entrance  junction  (e.g., 
Fred  or  Mary  may  be  the  agent),  only  conditions  and  products  can  be  linked 
to  exit  junctions. 

•  DO:  This  stands  for  a  divergent  OR  junction  and  is  similar  in  structure  to  the 
DA  junction.  In  this  case,  however,  only  one  branch  of  the  outputs  will  be 
activated.  Thus  in  Figure  3-4,  either  product_A,  product_B,  or  condition_A 
will  activate. 


<111111111)11111^11  o  ~ 

-H  product, A  | 

do 

r— |  condition  A| 

hmM  exit  ctrnposrtB  ^^**— — *^ 

T 

1  product_B  | 

|  actrvity_A  | 

Figure  3-4  Example  of  a  “DO”  Junction 


It  should  be  noted  that  if  multiple  conditions  and/or  products  tie  directly  into  an  activity,  then 
by  default  these  are  all  assumed  to  be  conjoined  (i.e.,  no  CA  box  is  needed).  The  same  rule 
applies  for  conditions/products  exiting  an  activity  (i.e.,  no  DA  box  is  needed).  This  default  can 
be  seen  in  Figure  3-2.  Finally  Figure  3-5  illustrates  a  complex  boolean  expression  as  input  to 
an  activity  which  in  turn  generates  a  product  and  sets  a  condition. 
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The  last  required  basic  concept  is  that  of  iteration.  This  is  easily  accommodated  within  the  ex¬ 
isting  notation.  Iteration  is  required,  for  example,  when  a  product  undergoes  a  series  of  revi¬ 
sions,  where  each  revision  is  different  from  the  last.  Figure  3-6  illustrates  the  implementation. 
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A  change  request  (CR)  is  initially  composed  at  which  time  the  incrementing  variable  is  set  to 
an  initial  value  (initialize  CR  /  i=1).  Each  time  the  change  request  is  updated,  the  variable  is 
incremented  ( update  CR  /  /++).  Versions  of  products  are  tagged  with  the  variable  /,  and  hence 
versions  of  the  product  are  defined.  Thus  revision  request  /  i  represents  the  P  version  of  the 
change  request.  Clearly,  nested  loops  can  be  implemented  using  this  notation.  It  should  be 
noted  '-iat  the  nomenclature  used  to  increment  versions  (i.e.,  /  /,  /  i++,  and  /  /=/)  is  not  part  of 
the  P  oNet  tool.  This  is  simply  a  notational  convention.  The  terms  i++  etc.  are  simply  added 
after  the  entity  names  when  these  entities  are  defined. 

3.2.2  Some  Properties  of  Stores 

Stores  support  collections  of  product  and  condition  values,  and  thus  allow  for  the  modeling  of 
persistency  of  generated  entities.  Since  we  must  be  able  to  add  these  entities  to  or  retrieve 
these  entities  from  a  store,  we  introduce  two  special  activities.  These  do  not  generate  prod¬ 
ucts,  conditions,  etc.,  but  add  products  to  and  remove  products  from  a  store.  The  activity 
types  (put,  get}  are  illustrated  in  Figure  3-7  and  are  added  on  to  the  front  of  the  activity  name 
as  shown  in  the  figure.  Note  that  in  the  case  of  the  put  operation,  there  must  always  be  an 
exit  condition  stating  that  the  activity  has  taken  place.  Likewise,  in  the  get  operation,  an 
entrance  condition  must  be  present  in  order  for  the  operation  to  be  initiated. 


Figure  3-7  Definition  of  Activities  Associated  Only  with  “Store”  Entities 


3.3  Relationship  to  Other  Modeling  Techniques 

The  approach  to  process  modeling  taken  by  ProNet  has  connections  to  other  modeling  nota¬ 
tions.  In  particular,  there  are  similarities  to  Petri  Nets,  entity-relationship  models,  state  transi¬ 
tion  diagrams,  and  data  flow  diagrams.  ProNet  can  also  be  interpreted  in  a  declarative  rule- 
based  sense.  However,  since  this  is  discussed  in  some  detail  in  Section  4,  it  is  not  dealt  with 
here. 

Petri  Nets  [Reisig  82]  were  initially  developed  to  model  synchronous  and  asynchronous  events 
in  communication  systems.  These  nets  consist  of  three  types  of  elements  which  can  be  dis- 
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played  graphically:  places  (denoted  by  circles),  transitions  (denoted  by  rectangles),  and  direct¬ 
ed  arcs.  Arcs  connect  places  to  transitions  and  transitions  to  places.  In  addition,  the  concept 
of  tokens  (which  are  inserted  into  places)  is  used  for  process  enaction  to  mark  a  place  which 
has  been  asserted  in  some  way  (e.g.,  is  made  “true";.  Thus,  the  Petri  Net  concept  of  place  is 
a  generalization  of  the  ProNet  concepts  of  conditions,  products,  or  even  agents.  The  Petri  Net 
transition  is  comparable  to  the  ProNet  concept  of  activity.  In  Petri  Nets,  transitions  are  never 
connected  directly  to  other  transitions.  In  the  same  way,  ProNet  .activities  are  not  generally 
connected  directly  to  other  activities  (the  exceptions  being  through  the  inheritance,  aggrega¬ 
tion  and  custom  relationships). 

The  connection  between  ProNet  diagrams  and  entity-relationship  (E-R)  diagrams  [Chen  83]  is 
a  fairly  direct  one.  E-R  diagrams  define  entities  connected  by  directed  arcs,  and  names  de¬ 
scribe  the  relationships  (i.e.,  arcs)  between  the  entities.  Entities  may  have  attributes  or  prop¬ 
erties  and,  in  the  database  world,  these  can  stored  in  tables.  However,  it  is  the  concept  of 
relationship,  rather  that  the  concept  of  data  structure,  which  is  of  importance  to  ProNet.  (See 
Section  4.5  for  a  brief  discussion  of  a  data  structure  interpretation  of  ProNet.)  While  E-R  rela¬ 
tionships  can,  in  general,  take  on  arbitrary  values,  in  a  ProNet  model  the  relationsh  is,  such 
as  is  exit  condition  for,  come  from  a  predefined  small  typed  set.  (An  exception  to  this  rule  is 
the  custom  relationship  discussed  in  Section  3.1.) 

State-transition  networks  [Harel  87],  based  on  finite-state  machines,  can  be  used  to  model  the 
dynamic  (or  behavioral)  aspects  of  process.  Such  networks  model  states,  events  and  the  re¬ 
lationships  between  them.  An  event  occurs  (in  theory)  instantaneously  and  represents  control 
or  stimulus  information  required  to  activate  a  new  state.  A  state  can  represent  a  particular  con¬ 
figuration  of  objects  and  may  have  an  implied  activity  associated  with  it.  Through  this  activity, 
new  events  may  be  activated.  In  process  modeling,  the  state-transition  concept  of  state  cor¬ 
responds  to  the  ProNet  concept  of  activity  while  the  concept  of  event  corresponds  loosely  to 
the  ProNet  concepts  of  condition.  While  a  product  may  be  interpreted  as  a  physical  object,  its 
existence  or  lack  of  existence  can  also  be  interpreted  as  a  condition. 

Finally.  ProNet  has  much  in  common  with  data-flow  (or  functional)  modeling  techniques  [Your- 
don  89],  Data-flow  diagrams  define  activities  and  the  £.  .facts  which  flow  between  them.  They 
also  allow  for  stores  in  which  artifacts,  generated  by  the  activities,  are  kept,  or  retrieved.  They 
do  not,  however,  consider  the  temporal  sequence  in  which  these  activities  occur  and  thus  do 
not  consider  behavior.  ProNet  borrows  several  concepts  from  data-flow  diagrams: 

•  activities  play  a  central  role, 

•  stores  are  used  to  contain  artifacts, 

•  activities  can  be  hierarchically  nested,  and 

•  artifacts  are  explicitly  generated  by  some  activities  and  consumed  by  others. 

However,  ProNet  has  a  combination  of  features  which  make  it  unique.  First,  it  was  designed 
explicitly  for  software  process  modeling,  and  its  entity  classes  are  tailored  to  this  goal.  Second, 
it  was  developed  so  that  there  is  a  direct  and  unique  correspondence  between  graphical  pro- 
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cess  modeling  in  ProNet  and  the  symbolic  enactment  model  (as  will  be  seen  in  Section  4). 
Third,  ProNet  provides  for  version  management  within  a  process  definition/enactment  context 
and  provides  for  persistency  of  entities  generated  during  enactment.  Finally,  the  underlying 
model  provides  a  basis  for  process  verification  (as  will  be  seen  in  Section  5). 

3.4  A  ProNet  Example 

To  illustrate  the  modeling  concepts  discussed  in  ProNet,  the  following  simple  change  request 
example  is  given.  While  this  example  is  small,  it  illustrates  many,  but  not  all,  of  the  concepts 
which  may  go  into  a  ProNet  model.  For  a  large  and  detailed  ProNet  model  of  a  real  software 
maintenance  organization,  [Slomer  92]  should  be  consulted. 

Figure  3-8  shows  the  model.  In  this  figure,  the  major  process  flow  lines  have  been  highlighted 
for  clarity.  In  addition,  it  should  be  noted  that  certain  of  the  activities  have  circled  numbers  next 
to  them.  These  activities  are  the  main  ones  which  will  be  discussed  with  respect  to  process 
enaction  in  the  next  section.  One  general  point  should  be  made  about  reading  ProNet  process 
diagrams:  they  do  not  have  arrows  indicating  in  which  direction  the  process  is  flowing  in  time. 
Rather,  the  dots  on  the  lines  connecting  the  entities  provide  relationship  information,  not  tem¬ 
poral  process  flow  information.  To  initiate  the  process,  entry  products  or  entry  conditions  are 
placed  along  the  left-hand  edge  of  the  diagram,  in  this  case  the  process  starts  with  either  the 
condition  extern _prob_iden  cr  intern _prob_iden.  Similarly,  the  process  terminates  with  exit 
products  or  conditions  being  placed  along  the  right-hand  edge  of  the  diagram.  In  this  case 
there  is  one  exit  condition,  cr_appr.  Thus,  the  process  can  be  followed  by  starting  on  the  left 
of  the  diagram  and  working  over  to  the  right. 

The  process  can  start  when  either  the  condition  extern _prob_iden  or  intern _prob_iden  is  initi¬ 
ated.  This  means  that  an  initial  problem  can  be  Identified  either  externally,  such  as  by  a  field 
representative,  or  internally  such  as  by  a  developer.  When,  for  example,  the  condition  extem_- 
prob_iden  is  set  to  true,  the  activity  devel_extem_cr  can  proceed.  The  resulting  product  is  the 
initial  version  of  the  change  request,  field_cr.  This  version  is  then  electronically  transmitted  to 
the  central  office  where  it  is  identified  as  crjextem.  CRs  generated  internally  are  designated 
by  crjntern.  In  either  case  the  responsible  developer  formats  the  CR  messages  (format_cr  / 
k=  1)  suitable  for  inclusion  in  the  CR  repository.  At  this  point,  the  CR  version  indicator  /  is  ini¬ 
tiated  to  1 .  The  output  of  this  activity  is  crl/1.  The  first  “1"  indicates  from  which  activity  the  CR 
has  come  (This  is  necessary  for  process  enaction,  as  will  be  described  later.)  The  second  “1" 
is  the  CR  version  number. 

The  next  two  activities  are  related  to  the  repository.  The  put  prefix  on  the  activity  indicates  that 
the  entrance  product  will  be  stored  in  the  repository,  c rjrepos,  linked  to  this  activity.  While  the 
developer  puts  version  k  of  the  change  request  into  the  repository  cr_repos,  the  reviewer  re¬ 
moves  (i.e.,  gets)  a  copy  of  the  same  version  of  the  CR  for  review.  If  the  change  request  pass¬ 
es  the  review  then  the  condition  cr_appr  is  generated;  otherwise,  version  k  of  the  product 
rev_doc  is  generated.  It  will  be  noticed  that  there  are  three  activities  all  with  the  name  get_- 
from_repos.  These  activities  are  distinguished  with  the  suffixes  A  B,  and  _C  respectively. 
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Figure  3-8  A  More  Complex  Change  Request  Process  Model 
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Beyond  this  point,  the  developer  retrieves  the  appropriate  version  of  the  change  request  and 
the  corresponding  review  document,  rev_doc2,  makes  updates  to  the  change  request,  cr3, 
and  puts  the  updated  change  request  ( cr4  /  fc)  back  into  the  repository  cr_repos.  Note  that  the 
version  number  k  is  incremented  before  the  exit  product  crl  /  k  is  generated. 

ProNet  has  been  implemented  in  prototype  form  using  HyperCard  2.0™  on  the  Apple  Macin¬ 
tosh™. 
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4  Enacting  the  Process 


This  section  describes  how  the  ProNet  language  defined  in  Section  3  can  be  used  as  a  basis 
for  generating  an  enactable  model  (see  Step  2  in  Figure  2-1).  As  discussed  in  Section  2,  the 
focus  of  this  report  is,  in  part,  to  investigate  issues  associated  with  developing  enactable  pro¬ 
cess  specification.  Thus  the  implementation  of  the  PCDE  (which  would  use  the  specification) 
will  not  be  discussed. 

The  approach  taken  to  enactment  uses  logic  programming.  Logic  programming  and  its  princi¬ 
ple  implementation  Prolog  [Bratko  86],  have  previously  been  used  by  various  researchers  [He- 
imbigner  90,  Lee  91],  and  appear  to  be  effective  in  capturing  process  data  and  enacting 
process  models.  Prolog’s  declarative  characteristics  not  only  allow  for  straightforward  map¬ 
ping  between  the  graphic  and  symbolic  forms  of  the  model,  but  also  provide  an  effective  tool 
for  developing  the  driver  through  which  a  process  can  be  enacted. 

4.1  Mapping  Activities  to  Rules 

The  manner  in  which  the  defined  process  is  made  enactable  is  not  rigorous  in  a  mathematical 
sense,  but  requires  1 )  identifying  appropriate  Prolog  rules  for  specific  process  model  elements 
and  2)  generalizing  these  rules.  The  mapping  exercise  has  been  conducted  using  the  process 
elements  of  Figure  3-8.  These  elements  do  not  cover  all  of  ProNet’s  modeling  features  but  do 
provide  sufficient  generality  to  indicate  that  the  approach  has  a  high  chance  of  success. 

Returning  to  Figure  3-8,  it  can  be  seen  that  before  any  activity  is  performed,  certain  entrance 
conditions  must  be  true.  For  example,  in  order  to  review  version  3  of  the  change  request  (re- 
view_ci),  the  product  cr2  /  3  must  be  available,  in  addition,  neither  the  condition  cr_appr( i.e., 
the  change  request  has  been  approved)  nor  the  product  rev_doc1  /  3  must  exist  prior  to  exe¬ 
cution  of  the  review_cr  activity.  If  all  of  these  conditions  are  met,  then  the  activity  cr_review 
can  take  place  and  either  crjapprox  rev_doc 7/3 can  be  generated.  During  process  enactment, 
a  sequence  of  statements  (called  log  statements)  is  generated.  These  leave  a  trace  of  what 
activities  have  been  performed,  and  are  principally  required  to  assure  that  once  activities  have 
been  completed  they  are  not  performed  again.  On  completion  of  each  activity,  a  log  statement 
is  generated  and  added  to  the  database,  thus  indicating  that  the  activity  has  been  completed. 
A  tog  statement  contains  information  indicating  which  activity  has  been  completed,  what  inputs 
were  consumed  and  what  outputs  were  generated.  As  will  be  discussed  in  Section  5,  the  trace 
generated  by  the  log  statements  is  also  useful  in  supporting  the  audit  trail  required  for  process 
verification. 

The  above  discussion  provides  an  overview  of  the  enactable  model.  It  is  a  declarative  model 
in  which  each  activity  forms  the  core  of  a  rule.  A  variety  of  approaches  to  dynamically  enacting 
rules  exist.  Examples  include  tee  production  system  OPS5  [Brownston  85]  or  Prolog  [Bratko 
86].  Prolog  was  chosen  because  an  implementation  was  readily  available  and  tee  language  is 
appropriate  to  this  type  of  problem.  A  knowledge  of  Prolog  will  be  useful  in  the  discussions  be¬ 
low;  however,  an  understanding  of  the  general  approach  taken  should  not  require  a  prior  back- 
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ground  in  the  language.  The  activities  in  Figure  3-8  will  be  used  to  define  the  mapping 
procedure. 


Before  doing  this,  however,  a  simple  process  element  will  be  first  described  to  show  what  the 
structure  of  the  corresponding  rule  looks  like.  This  is  shown  in  Figure  4-1 .  Here  the  activity  ac- 
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actl:- 

prod_A, 

not  Gog  (activ_A,  cond_A)), 

assert  Gog  (activ_A,  [prod_A],  [cond_A])), 

assert  (cond_A). 


Figure  4-1  The  Mapping  Between  a  Simple  Process  Element  and  its  Prolog  Expression 


tiv_A  requires  product  prod_A  as  input  and  generates  the  output  condition  cond_A.  The  equiv¬ 
alent  Prolog  statement  is  shown  to  the  right  of  the  diagram.  This  statement  indicates  that  1) 
prod_A  must  exist  in  the  Prolog  database  prior  to  performing  the  activity,  and  that  2)  the  activ¬ 
ity  activ__A  has  not  yet  been  performed  (through  the  not  (log  ( activ_A ,  _,  cond_A))  statement). 
When  those  two  conditions  are  true,  the  statement  (log  ( activ_A ,  prodA,  cond_A))  is  added 
to  the  Prolog  database  through  the  assert  statement.  This  indicates  that  the  activity  has  now 
been  performed  and,  as  a  result,  the  output  condition  cond_A  can  be  added  to  the  database. 
The  square  brackets  around  the  entities  indicate  lists  in  Prolog  (albeit,  in  the  above  cases,  one 
element  lists). 

The  above  example  illustrates  that  each  activity  can  be  treated  as  a  separate  chunk  of  knowl¬ 
edge  and  is  not  explicitly  coupled  to  any  other  activity.  This  allows  for  easier  incremental 
growth  of  the  model.  The  generation  of  outputs  from  the  activity  (e.g.,  cond_A)  then  allows  oth¬ 
er  activities  to  be  initiated.  In  order  for  an  activity  to  be  initiated,  not  only  must  the  entrance 
conditions  be  satisfied,  but  the  activity  cannot  have  taken  place  already.  This  is  tested  for  by 
the  not  ( log() )  statement.  We  now  look  at  a  variety  of  typical  process  elements  extracted  from 
Figure  3-8.  The  examples  to  be  discussed  are  associated  with  the  numbered  activities  in  Fig¬ 
ure  3-8.  As  a  result  of  examining  these  examples,  we  will  be  able  to  define  a  more  general 
expression  for  the  graphic-to-symbolic  mapping.  Once  this  is  completed,  we  will  then  show 
how  the  resulting  rules  can  be  used  as  part  of  an  enactable  model. 

Figure  4-2  (1  in  Figure  3-8)  shows  the  initial  activity  in  the  process.  Note  that  the  role  involved 
(field_rep)  is  not  specified  in  the  rule.  The  manner  of  specifying  the  agents  associated  with  ac¬ 
tivities  will  be  discussed  later.  The  symbolic  form  of  this  process  element  is  conceptually  very 
similar  to  the  example  of  Figure  4-1 .  Figure  4-3  (2  in  Figure  3-8)  illustrates  a  more  complex 
activity.  In  this  activity,  either  the  initial  change  request  or  a  revised  change  request  is  inserted 
into  the  database.  The  1  extension  on  cr(i.e.,  crl)  removes  potential  ambiguity  from  other,  oth¬ 
erwise  identically  named  o’ s  generated  by  different  activities  (for  example,  see  cr2  in  Figure 
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Figure  4-2  The  Initial  Step  In  the  Process 


4-5).  Version  information  is  supplied  by  the  version  number  after  the  vertical  bar  (for  example, 
the  k  in  crl  /  *). 


The  next  two  rules,  put_into_repos_A  and  getjrom  repos_A,  deal  with  database  support. 
These  process  elements  and  their  corresponding  rules  are  shown  in  Figures  4-4  and  4-5  and 
can  be  identified  in  Figure  3-8  (3  and  4  respectively).  In  Figure  4-4,  the  version  of  the 
change  request  is  stored  in  the  database  crjrepos.  (Within  the  Prolog  implementation,  this 
simply  means  that  the  name  cr(1)  is  stored  as  an  element  of  a  list,  called  crjrepos,  of  cr  ver¬ 
sions.)  The  first  statement  in  this  rule  ( ver(k,K ))  is  added  in  order  to  instantiate  the  value  of  the 
variable  k.  To  indicate  to  other  interested  activities  that  this  task  has  been  accomplished,  the 
condition  cr_added(k)  is  generated.  Notice  that  this  condition  must  also  be  given  a  version 
number.  The  function  put_ent  in  the  Prolog  rule  of  Figure  4-4  is  responsible  for  adding  the 
change  request  to  the  database  and  also  issuing  the  message  that  the  transaction  has  taken 
place.  Finally,  it  should  be  noted  that  the  putin  front  of  the  activity  name  put_into_repos_A  has 
a  special  significance  in  that  this  activity  performs  a  put  operation  into  the  database.  The  get 
operation  is  the  inverse  of  the  put  operation.  Thus  a  condition  is  required  to  initiate  a  get  and 
the  get  activity  results  in  a  copy  of  an  entity  in  the  database  being  released. 
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Figure  4-5  Removing  a  Product  from  a  Database 

The  review  activity  (5)  can  have  two  outcomes:  either  the  review  succeeds  (and  it  generates 
the  condition  cr_appr,  or  it  fails  to  pass  the  change  request,  in  which  a  review  document  rev_- 
docl  I  k  is  written.  The  process  element  for  this  is  shown  in  Figure  4-6.  Note  that,  as  with  any 
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Figure  4-6  Making  a  Decision 
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divergent  OR  statement  (the  DO  box),  a  decision  must  be  made  as  to  which  path  to  take.  For 
simulation  purposes,  the  decision  function  makes  this  choice  based  on  a  random  number  and, 
through  this  function,  the  probability  of  which  decision  is  made  can  be  varied. 


The  process  element  for  the  activity  put_into_repos_B  (6)  is  shown  in  Figure  4-7.  This  is  very 


Figure  4-7  Generating  Multiple  Output  Decisions 


similar  to  the  insertion  of  a  product  into  a  database  as  shown  in  Figure  4-4.  However,  this  el¬ 
ement  generates  two  identical  output  conditions,  rev_doc_added1  and  rev_doc_added2.  This 
redundancy  is  not  required  for  process  enactment,  since  get_from  repos_B  and  get_from_re- 
pos_C  could  use  the  same  output  condition  during  process  enactment,  but  it  is  required  for 
process  verification  (as  will  be  described  in  Section  5).  The  final  activity  to  be  illustrated  is  up- 
date_cr  (7  in  Figure  3-8).  This  is  shown  in  Figure  4-8  and  demonstrates  two  modeling  con¬ 
cepts.  First  it  shows  how  two  entrance  products  (in  this  case,  cr3  and  rev_doc2)  support  an 
activity  through  the  use  of  the  convergent  AND  (CA)  junction.  Secondly,  it  shows  how  a  ver¬ 
sion  number  is  incremented.  The  products  entering  the  activity  are  associated  with  the  unin¬ 
cremented  number  while  the  exit  product  is  associated  with  the  incremented  number. 

4.2  Generalizing  the  Rules 

The  above  example  and  the  associated  Figures  4-2  through  4-8  provide  insights  into  how  to 
define  the  graphics-to-symbolic  mapping.  Table  3  provides  a  general  procedure  for  performing 
this  mapping.  It  can  either  be  used  as  a  basis  for  manually  mapping  a  graphically-defined  Pro- 
Net  process  or  as  a  mechanism  for  developing  a  computer-based  approach.  The  latter  has 
not,  to  date,  been  done.  This  procedure  is  applied  to  each  activity  and  the  entities  (i.e.,  prod¬ 
ucts  and  conditions)  upon  which  the  activity  is  dependent.  Table  3  has  three  columns.  The  first 
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Figure  4-8  Combining  inputs  and  Incrementing  a  Version  Number 


Table  3  Mapping  a  Graphical  ProNet  Model  to  Its  Enactable  Form 


Mapping  Task 


Example  Statements 


1  I  Identify  input  entities 


Identify  output  entities 


Add  ver  statements  for  versions 


Add  temporary  increment  statements 


•5  Assert  input  entities: 


Sa  convergent  AND  (CA) 


5b  I  convergent  OR  (CO) 


*6  Test  for  existence  of  log  statements: 


6a  divergent  AND  (DA) 


6b  I  divergent  OR  (DO) 


Assert  log  statements: 


7a  convergent  AND  (CA), 
divergent  AND  (DA) 


7b  convergent  AND  (CA), 
divergent  OR  (DO) 


7c  convergent  OR  (CO), 
divergent  AND  (CA) 


prod_ai,  prodb,  condc 


prod_x,  cond_yj 


vei(i.  I).  ver(j,  J), 


II  isl  +  1 


prod_aj,  prod_b,  cond_c. 


(prod_ai,  X=prod_ai;  prod_b.  X=prod_b. 
cond_c,  X=prod_c), 


not  (log  (act_A,  [prod_a,,  prod_b,  cond_c])X 


not  (log  (act_A,  _,  (prod_a,]))t 
not  (log  (act_A,  _,  [prod_b])), 
not  (log  (act_A,  _,  [cond_c])). 


assert  (log  (act_A,  [prod_a1,  prod_b,  cond_c], 
lprod_x,  cond_yj])). 


decision  (prod_x,  cond_yj,  Y), 
assert  Gog  (act_A,  [prod_a,,  prod_b,  cond  c), 
Y)). 


assert  Gog  (act_A,  X,  [prod_x,  cond_yj])). 


(X  as  in  5b  above) 
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Table  3  Mapping  a  Graphical  ProNet  Model  to  Its  Enactable  Form 


D 

Mapping  Task 

Example  Statements 

7d 

convergent  OR  (CO) 
divergent  OR  (DO) 

decision  (prod_x,  cond_yj,  Y), 
assert  (log  (act_A,  X.  Y)), 

(X  as  in  5b  above) 

8 

Add  item  to  database  (put_ ...) 

put_ent  (repository_A,  prod_b,  [b_added]). 

9 

Remove  item  from  database  (get  ...) 

get_ent  (repository_A,  prod_x,). 

*10 

Assert  output  entities: 

10a 

divergent  AND  (DA) 

assert  (prod_x), 
assert  (cond_yp. 

10b 

divergent  OR  (DO) 

assert  (Y). 

Y  as  in  7b  above 

11 

initialize  version  numbers 

set(i,l). 

12 

increment  version  numbers 

ine(i). 

column  lists  the  item  number.  Some  of  these  items  are  mandatory  and  must  be  included  in 
every  Prolog  rule  (these  are  identified  with  an  asterisk).  Other  items  have  sub-items  (a,  b,...) 
which  may  be  chosen  depending  on  the  nature  of  the  current  process  element.  For  example, 
if  the  current  process  element  has  a  DO  as  an  output,  items  6b,  7b  or  7d,  and  1 0b  are  chosen. 
Note  that  in  Table  3,  the  only  functions  defined  within  the  Prolog  language  are  not  and  assert. 
All  other  statements  and  functions  (e.g.  decision  and  put-ent)  are  defined  as  part  of  the  rule- 
driver. 

To  complete  the  discussion  of  the  process  model,  three  additional  topics  are  addressed. 
These  deal  with: 


•  the  actual  rule  structure, 

•  modeling  the  agents  which  perform  the  activities,  and 

•  the  rule  driver  through  which  the  rules  are  enacted. 

In  the  actual  implementation,  each  rule  is  separated  into  two  parts.  In  the  first  part,  the  en¬ 
trance  conditions,  which  test  whether  the  rule  should  fire,  are  grouped  into  a  ‘test’  category 
(under  the  heading  test).  These  are  items  5  and  6  in  Table  3.  Then  the  assertions,  stating  that 
the  activity  has  taken  place  and  that  the  output  products  and  conditions  have  been  generated, 
are  placed  in  a  second  "action”  category  (under  the  heading  act).  These  are  items  7  through 
12  in  Table  4.1  .This  separation,  which  can  be  seen  in  the  program  listing  provided  in  Appendix 
A.2,  is  required  in  order  to  find  all  satisfied  entrance  conditions  prior  to  performing  any  activity. 
This  provides  a  list  of  current  actions  which  are  then  presented  to  the  user.  Statements  linking 
each  entrance  condition  to  its  action  are  defined  and  have  the  form  actRole(test3,  act3,  field_- 
rep,  'e-mail  external  CR'),  where  the  test  test3  is  linked  to  the  action  act3.  The  third  field  in  this 
actRole  data  statement  defines  which  role  (e.g.,  field_rep)  can  perform  this  activity,  while  the 
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last  field  provides  textual  information  about  the  activity  {'e-mail  external  CR).  It  should  be  not¬ 
ed  that  when  an  activity  is  performed,  some  implicit  events  may  take  place.  For  example,  tools 
may  be  invoked  to  perform  the  actual  operations,  or  subprocesses  may  be  invoked  to  define 
lower  levels  of  process  granularity.  Invocation  of  tools  is  not  investigated  in  this  paper.  How¬ 
ever,  in  Appendix  A.3  an  extension  of  the  model  defined  in  Section  4  illustrates  how  the  ap¬ 
proach  can  be  generalized  to  account  for  hierarchies  of  sub-processes. 

The  second  topic  relates  to  how  agents  are  modeled.  Each  activity  should  have  one  or  more 
attached  roles  (or  agents)  responsible  for  the  implementation  of  that  activity.  Prior  to  the  actual 
performance  of  an  activity,  we  must  assign  actual  agents  to  these  roles.  While  these  agents 
are  often  persons,  they  can  also  be  non-living  entities  such  as  a  specific  compiler  version  with 
specific  flags.  The  mapping  between  the  role  and  the  actual  agent  is  given  by  statements 
which  have  the  form:  hasRole(field_rep,  howard).  Hence  a  list  of  hasRole  statements  must  be 
part  of  the  process  definition  in  the  enactable  model. 

Using  Table  3,  the  rules  which  define  the  process  can  be  generated.  However,  in  order  to 
make  the  process  enactable,  a  rule  driver  is  required.  While  the  rules  themselves  are  depen¬ 
dent  on  the  process  being  defined,  the  rule  driver  is  process  independent  and  controls  the  or¬ 
der  in  which  rules  are  fired  as  the  process  is  enacted.  The  rule  driver  is  discussed  in  somewhat 
more  detail  in  Section  4.3,  as  this  pertains  to  how  the  enactable  model  is  used  in  a  process 
context. 

Details  of  the  full  model,  as  described  in  Section  4,  can  be  found  in  Appendix  A.  This  provides 
sample  output  from  the  demo  process  controller  and  lists  the  Prolog  program,  including  the 
test  entrance  conditions,  the  act  activities,  the  actRole  and  hasRole  definitions  and  the  rule 
driver. 


4.3  User  Interaction  with  the  Process  Model 

Let  us  first  look  at  how  a  user  would  interact  with  our  simple  enactable  process  model  and  then 
address  the  issue  of  managing  a  large  rule-base.  We  have  referred  above  to  the  rule  driver, 
that  is,  the  part  of  the  system  which  selects  and  displays  appropriate  information  (e.g.,  current 
activities)  to  the  user.  From  an  implementation  point  of  view,  the  name  rule  driver  is  appropri¬ 
ate,  but  from  the  perspective  of  a  user  of  the  process,  it  is  not.  In  this  section  it  is  more  appro¬ 
priate  to  rename  it  as  the  process  controller. 

The  structure  of  the  process  controller  is  shown  in  Figure  4-9.  It  is  (of  course)  defined  in  ProNet 
notation.  After  the  project  is  initiated,  or  after  any  project  activity  has  been  completed,  a  list  of 
all  candidate  activities  which  can  currently  be  performed  is  generated.  If  this  list  is  empty  then 
the  project  has  been  completed.  If  the  list  is  not  empty  then  a  subset  of  the  list  is  generated 
which  applies  to  the  current  user.  The  user  then  specifies  which  activity  should  now  be  per¬ 
formed.  Thus  the  process  controller  cycles  round  the  activities  defined  in  the  rule-base  and  on 
each  cycle  performs  one  of  the  activities.  These  cycles  continue  until  the  candidate  list  no 
longer  contains  any  activities.  Thus  the  controller  acts  like  an  rule-based  production  system 
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Figure  4-9  Process  Controller  for  the  Enactable  ProNet  Model 

[Brownston  85].  From  the  above  discussion  and  the  model  shown  in  Figure  4-9,  it  should  now 
be  clear  why  the  activity  entrance  conditions  are  separated  from  the  actual  activities.  The  en¬ 
trance  conditions  must  all  be  checked  in  order  to  generate  the  activity  list  prior  to  candidate 
activity  selection.  (This  selection  process  is  the  manual  equivalent  to  conflict  resolution  in  a 
production  system.)  While  the  process  is  being  enacted,  products  and  conditions  are  being 
generated,  product  versions  are  being  added  to  and  removed  from  databases,  and  a  history 
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of  the  user  defined  process  path  used  is  being  stored.  Appendix  A.1  provides  sample  output 
from  a  user  interacting  with  the  process  controller. 

4.4  Managing  the  Rules 

Declarative  rule-based  modeling,  as  discussed  earlier,  has  appealing  properties  with  respect 
to  building  models  incrementally.  Since  each  rule  defines  an  isolated  activity,  it  is  relatively 
easy  to  build  on  or  modify  models  as  confidence  and  insight  increase.  In  order  to  manage  the 
large  number  of  process  model  variants  which  are  likely  to  arise,  configuration  management 
of  these  models  will  be  essential. 

One  concern  with  the  declarative  approach  is  that  of  verification.  With  any  complex  process, 
the  numbers  of  rules  may  run  into  the  hundreds.  Thus  the  complexity  of  interactions  can  be 
high,  and  verifying  behavioral  correctness  or  completeness  may  be  difficult.  Performing  tests, 
such  as  for  deadlock  and  reachability,  will  help  to  reduce  errors.  In  addition,  process  enact¬ 
ment  simulation  will  help  to  assure  that  the  additions  or  improvements  are  well  behaved  before 
they  are  fielded.  A  second  verification  issue  is  related  to  assuring  that  the  agents  that  pro¬ 
duced  the  end-products  actually  use  the  defined  process.  The  log  statements  defined  above 
help  provide  a  trace  of  the  process  used  to  develop  the  products.  Through  this  trace,  this  his¬ 
torical  process  can  be  identified  and  verified  against  the  defined  process.  This  is  the  main  topic 
of  Section  5. 

4.5  User  Interaction  with  the  Automated  Process 

A  problem  discussed  in  Section  3  is  that  of  unnecessarily  restricting  the  start  of  an  activity  until 
all  the  necessary  entrance  conditions  are  met.  In  reality  there  are  many  cases  where  prelimi¬ 
nary  work  can  be  performed  on  an  activity  prior  to  that  point  when  all  the  formally  specified 
entrance  conditions  are  satisfied.  This  restrictive  behavior  is  unfortunately  exhibited  by  the 
above  model.  However,  the  problem  can  be  overcome  in  the  following  simple  way.  Rather 
than  prevent  the  start  of  any  activity,  the  process  controller  only  requires  that  the  exit  products 
and  conditions  of  the  activity  become  available  after  all  the  activity’s  inputs  exist.  Thus  an  ac¬ 
tivity  can  be  started  at  any  time  during  the  process;  the  only  imposed  constraint  is  that  the  ac¬ 
tivity  cannot  terminate  until  all  the  inputs  are  accounted  for  (and  of  course,  the  activity  itself 
has  been  performed). 

Another  restriction  on  the  current  model  is  that  the  process  driver  only  accounts  tor  forward 
chaining  and  not  backward  chaining.  Forward  chaining  implies  that  activities  are  performed 
only  when  their  entrance  conditions  are  met  (as  described  in  the  previous  paragraph).  How¬ 
ever,  it  could  be  that  an  agent  wishes  to  perform  an  activity,  some  of  whose  entrance  condi¬ 
tions  are  not  met.  The  agent  may  wish  to  satisfy  that  constraint  by  "backtracking"  through  the 
sequence  of  as-yet  unperformed  activities  in  order  to  generate  the  unmet  entrance  condition. 
Figure  4-1 0  provides  a  simple  example.  Assume  that  activity  A,  activity  E,  and  activity  F  have 
been  completed. 
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The  agent  next  wants  to  start  on  activity  G.  However,  prod  3  is  not  yet  available.  To  generate 
prod  3,  activity  C  must  be  performed.  This  in  turn  requires  activity  B  be  performed.  Hence  to 
satisfy  the  entrance  conditions  to  activity  G,  one  option  is  to  'backtrack”  through  these  unper¬ 
formed  activities  necessary  to  support  prod  3.  This  control  scheme  is  tighter  than  the  one  dis¬ 
cussed  immediately  above,  in  that  is  still  requires  all  input  entities  to  be  available  before  an 
activity  can  be  started.  However,  it  does  allow  an  agent  to  start  an  arbitrary  activity  at  any  time; 
the  system  will  then  guide  the  user  to  perform  the  necessary  precursor  activities. 

A  limitation  of  process  enaction,  as  it  has  been  described,  is  related  to  the  manner  in  which 
activities  are  displayed  to  the  user.  The  simple  user  model  presented  provides  a  list  of  possible 
“next"  activities  to  be  performed  (see  Appendix  A.1).  However,  this  provides  no  context  in 
which  to  make  the  selection.  A  significantly  improved  interface  would  show  the  graphical  pro¬ 
cess  model,  driven  by  real-time  execution  data,  and  indicating  project  status  [Mi  1992].  Color 
or  symbolic  coding  of  such  information  as  the  degree  of  activity  completion  or  ownership  of 
activities,  would  provide  instant  feedback  on  and  control  of  the  project.  By  clicking  on  an  ac¬ 
tivity,  the  agent  would  thus  open  that  task  for  development. 

4.6  A  Relational  Definition  of  the  ProNet  Notation3 

As  discussed  in  Section  3,  a  model  defined  using  ProNet  notation  has  elements  in  common 
with  entity-relation  models.  However,  the  underlying  ProNet  modeling  and  enaction  concepts 
can  be  defined  at  a  meta-level,  also  using  a  relational  model  [Monarchi  92].  This  is  briefly  de¬ 
scribed  below. 

Using  Figure  3-6  as  the  basis  for  a  process  simulation,  we  might  cycle  through  two  unsuccess¬ 
ful  reviews  ( review  CR)  before  satisfying  the  reviewer  and  generating  the  condition  CR  OK. 
With  this  scenario,  we  would  produce  two  versions  of  the  revision  request  and  three  versions 
of  the  change  request  before  generating  the  CR  OK  condition.  Table  4  lists  the  information  that 
both  defines  the  process  model  and  uniquely  specifies  this  execution.  Note  that  executed  ac¬ 
tivities  (the  Xts),  product  and  condition  versions,  and  agents  assigned  to  executed  activities 
are  required  to  complete  the  specification  of  the  enacted  process.  Thus,  it  can  be  seen  that 
the  essential  entities  required  for  ProNet  enaction  are:  activities,  artifacts  (i.e.,  products  and 
conditions),  executed  activities  (XI ,  X2,  etc.),  artifact  versions  (1 ,2,3,  etc.),  roles  and  agents. 


3  I'd  like  to  thank  Alan  Brown  (or  suggesting  this  concept. 


CMU/SEI-93 -TR-4 


31 


Activities  Artifacts  Input  artifacts 


initialize  CR 
update  CR 
review  CR 


CR 

rev  req 
CR  OK 


update  CR 
update  CR 
review  CR 


rev  req 

CR 

CR 


Output  artifacts 


initialize  CR 
update  CR 
review  CR 
review  CR 


X2  CR  1 
X3  rev  req  1 
X3  CR  1 
X4  CR  2 
X5  rev  req  2 
X5  CR  2 
X6  CR  3 


XI  CR  1 
X2  rev  req  1 
X3  CR  2 
X4  rev  req  2 
X5  CR  3 
X6  CR  OK  1 


This  relational  database  approach  to  process  enaction  is  not  pursued  any  further  here,  but 
may  have  interesting  implications. 


32 


CMU/SEI-93-TR-4 


CMU/SEI-93-TR-4 


33 


5  Software  Process  Verification 


This  section  of  the  paper  presents  an  approach  to  assuring  that  any  software  product  meets 
the  requirements  of  the  defined  process,  while  at  the  same  time  accounting  for  deviations  from 
the  prescribed  process  [Stanley  92].  Process  verification,  as  defined  here,  is  a  post-analysis 
of  process  data  gathered  during  product  manufacture  (down  to  an  appropriate  level  of  granu¬ 
larity).  The  act  of  verification  will  identify  where  deviations  from  the  agreed-to  process  occurred 
and  allow  a  determination  of  the  severity  of  those  deviations.  (See  Step  9  in  Figure  2-1 ). 

Deviations  need  not  invalidate  a  non-conforming  process  path.  Indeed,  they  could  be  benign 
or  even  beneficial.  Some  process  changes  may  be  due  to  unforeseen  circumstances  such  as 
accounting  for  the  replacement  of  an  assigned  developer  by  another  developer  in  the  execu¬ 
tion  of  certain  tasks.  Others  may  be  made  to  allow  for  creative  improvements  such  as  the  re¬ 
placement  of  a  specified  compiler  by  a  more  efficient  one.  Whatever  deviations  occur,  a  post- 
project  evaluation  can  be  performed  to  assess  their  impact  on  the  resulting  software  quality, 
provided  that  the  enacted  process  is  tracked.  The  approach  to  verification  follows.  Throughout 
a  project,  the  artifacts  which  are  produced  by  the  developers  are  automatically  recorded,  along 
with  information  on  who  produced  them  and  how  they  were  produced.  On  project  completion, 
the  manner  in  which  these  artifacts  were  produced  is  then  compared  to  the  requirements  of 
the  defined  process. 

The  approach  taken  rests  heavily  on  the  process  modeling  concepts  described  in  previous 
sections.  In  particular,  the  log  statements  used  to  record  process  history  are  central  to  verify¬ 
ing  the  correctness  of  the  as-implemented  process.  If  the  process  has  been  followed  exactly 
as  specified  in  the  enactment  model,  then  a  set  of  log  statements,  consistent  with  the  defined 
process,  must  exist.  However,  as  described  above,  there  are  likely  to  be  situations  where  no 
path  through  the  implemented  process  matches  the  defined  process. 

Process  verification  affects  several  aspects  of  software  development.  First,  the  tools  used  to 
develop  the  software  will  have  to  be  instrumented  to  record  what  is  being  performed.  Second, 
there  are  implications  for  metrics  tools  since  process  data  will  have  to  be  recorded.  Third,  con¬ 
sistency  of  intermediate  product  versions  is  essential  to  assure  final  product  quality.  Hence, 
there  are  implications  for  configuration  management.  Finally,  there  are  implications  for  pro¬ 
cess,  process  specification,  and  process  modeling. 

It  should  be  noted  that  process  verification  can  be  the  basis  for  process  certification.  In  this 
context,  “process-certified”  software  implies  that  either  the  final  products  are  guaranteed  to 
have  been  generated  using  an  agreed  upon  process,  or  non-conformances  are  identified  and 
justified.  This  does  not  guarantee  that  the  software  performs  to  specification,  but  certification 
may  be  regarded  as  a  necessary  if  not  sufficient  guarantor  of  software  quality.  Such  certifica¬ 
tion  may  be  of  interest  to  any  organization  which  subcontracts  out  software  development. 
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5.1  The  Basis  for  Process  Verification 

The  basis  for  verification  has  already  been  laid  through  the  ProNet  notation  presented  in  Sec¬ 
tion  3  and  the  subsequent  discussion  on  process  enactment  in  Section  4.  The  verification  pro¬ 
cess  is  the  inverse  of  the  enactment  process.  In  enactment,  activities  follow  the  forward  flow 
of  time  and  the  events  are  recorded  (through  the  log  data  entities  as  described  Section  4). 
However,  verification  takes  place  by  starting  with  the  end  product,  applying  the  log  statements 
generated  during  process  enactment,  and  working  backwards.  The  object  here  is  to  prove  that 
the  process,  as  defined  through  the  log  statements,  is  consistent  with  the  defined  process  as 
reflected  through  the  process  model.  The  final  product  establishes  the  “initial  conditions  for 
verification,  and  one  log  statement  is  consumed  as  the  corresponding  activity  joins  those  in 
the  set  of  verified  activities.  While  this  approach  is  not  as  formal  as  proof  of  correctness  of  pro¬ 
grams  [Greis  81],  it  is  interesting  to  note  that  both  perform  their  verification  proofs  in  this  back¬ 
ward  manner. 

In  summary,  the  following  sequence  of  activities  is  performed  for  process  verification: 

•  Prior  to  initiation  of  the  software  project,  the  software  development  process 
is  established  using  an  appropriate  process  modeling  technique  such  as 
ProNet.  The  level  of  process  detail  should  be  such  that  important  products 
can  be  tracked. 

•  During  the  project,  all  critical  activities  are  instrumented  such  that  their  input 
and  output  products  and  conditions  (and  their  version  identifiers)  are 
recorded.  Conditions  must  be  tracked,  since  these  are  important  process 
indicators. 

•  When  the  final  product  has  been  generated,  comparison  is  made  between 
the  process  model  and  the  log  statements  generated  during  project 
execution.  For  verification  of  the  final  product,  complete  consistency  must 
exist  between  a  subset  of  the  intermediate  artifacts  produced  and  those 
expected  by  the  process  model. 


This  sequence  need  not  be  applied  only  to  a  complete  project.  If  the  project  is  sufficiently  large, 
then  intermediate  products  from  sub-projects  can  be  individually  verified  using  the  appropriate 
sub-processes.  These  intermediate  products  then  contribute  to  the  verification  of  products  at 
a  higher  level  in  the  overall  project. 

5.2  Implementing  the  Approach 

In  implementing  process  verification,  the  goal  is  to  prove  that  at  least  one  subset  of  the  col¬ 
lected  tog  data  statements  is  consistent  with  the  defined  process.  Figure  5-1  illustrates  the  el¬ 
ements  of  this  theorem-proving  approach.  The  diagram  in  Figure  5-1  shows  a  process  model 
element  in  which  products  prodl  and  prod2  support  activities  actl  and  act2,  and  where  these 
activities  generate  products  prod3  and  prod4.  This  process  is  defined  by  the  two  verify  state¬ 
ments  also  shown.  The  log  statements  represent  the  historical  data  gathered  during  execution 
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actl 


Process  model  data: 


verify :- 

ver(k,K), 

retract  (log  (act2,  [prod2(L),  prod3(M)J,  [prod4(K)])), 

assert  (prod3(M)), 

assert  (prod2(L)), 

retract  (prod4(K)), 

verify. 


verify :- 

ver(m.M), 

prod3(M), 

retract  (log  (actl,  [prodl(K),  prod2(L)],  [prod3(M)])), 

assert  (prodl(K)), 

retract  (prod2(L)), 

retract  (prod3(M)), 

verify. 


Tracking  Data: 

log  (actl,  [prodl(l),  prod2(l)],  [prod3(l)]) 
log  (actl,  (prodl(l),  prod2(2)j,  [prod3(2)]> 
log  (actl,  [prodl(2),  prod2(2)],  (prod3(3)]) 
log  (act2,  [prod2(3),  prod3(4)],  [prod4(l)]) 

Figure  5-1  A  Simple  Process  Model  with  Process  Data 

of  the  process.  The  first  log  statement,  for  actl,  uses  versions  vl  for  both  input  products  prodl 
and  prod2.  The  resulting  version  of  product  prod3  is  also  version  vl.  As  with  the  enactment 
model,  the  verification  model  is  written  in  Prolog  notation.  In  fact,  as  will  be  seen  later,  the  im¬ 
plementation  of  the  verification  procedure  is  very  similar  to  that  of  the  process  enactment  pro¬ 
cedure. 

Let  us  now  compare  the  process  model  data  (the  verify  statements)  with  the  tracking  data  (the 
log  statements).  The  first  verify  statement  asserts: 

IF 

prod4,  version  K  exists 
AND 
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activity  act?  generates  prod4,  version  K  as  output  and  uses  prod  2,  version  L  and  prod3, 
version  Mas  input 
THEN 

delete  the  tog  statement 

add  prod3,  version  M  and  ptod2,  version  L  to  the  database 

delete  prod4,  version  K from  the  database 

find  the  next  applicable  verify  statement  to  execute 


The  initial  ver  statement  in  the  verify  rule  simply  identifies  the  current  value  K  of  the  version 
number  k.  The  second  verify  statement  in  Figure5-1  has  a  construction  very  similar  to  the  first. 
The  values  L  and  M  of  version  numbers  /  and  m,  are  determined  when  the  appropriate  log 
statement  is  instantiated.  In  this  example.  prod4  takes  on  the  version  value  1 .  thus  forcing 
(through  the  log  statement  for  act2),  the  version  numbers  /  and  m  to  take  values  of  3  and  4 
respectively.  Hence  prod2,  version  3  and  prod3,  version  4  are  added  to  the  database.  Since 
prod3  is  now  in  the  data  base,  the  second  verify  rule  is  now  activated.  However,  there  is  no 
log  statement  which  has  prod3,  version  4  in  its  output  list  Hence  there  is  a  disconnect  in  the 
process,  and  the  verification  fails. 

This  simple  example  also  illustrates  how  the  process  verification  procedure  does  not  care  what 
activities  have  been  performed  (e.g.,  there  may  be  many  redundant  log  activities),  so  long  as 
there  is  a  core  set  which  can  be  threaded  together  consistently  as  defined  by  the  process  mod¬ 
el. 


5.3  The  Verification  Demo  Program 

As  with  process  enactment,  process  verification  is  implemented  through  a  rule-based,  forward 
chaining  production  system.  However,  unlike  the  enaction  program,  verification  is  not,  and 
does  not  need  to  be.  interactive.  The  “initial  conditions”  for  verification  are  the  name  of  the  final 
product  and  the  log  statements  generated  during  execution  of  the  project.  As  verification  takes 
place,  intermediate  products  appear  and  disappear  and  log  statements  are  consumed,  as  the 
valid  path  extends  further  backwards  in  time.  At  the  end  of  the  verification  procedure  (assum¬ 
ing  the  process  is  verified),  all  the  log  statements  associated  with  the  verified  path  will  have 
been  be  consumed  and  the  entry  products/conditions  for  the  process  will  be  generated.  The 
symmetry  between  process  enactment  and  verification  is  shown  in  Figure  5-2. 


exit  products/ 
conditions 
+ 

log  statements  of 
enacted  process 


Figure  5-2  Symmetry  Between  Process  Enactment  and  Verification 


entry  products/ 
conditions 


enactment 


verification 
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The  verify  program  is  listed  in  Appendix  B.  This  program  consists  of: 

•  a  set  of  clauses  to  support  needed  functionality,  such  as  for  adding  entities 
to,  and  removing  entities  from  stores, 

•  a  set  of  clauses  which  define  the  verification  rules,  each  rule  being 
associated  with  an  activity  in  the  defined  process,  and 

•  a  set  of  log  statements  which  were  previously  generated  during  process 
enactment. 

The  process  used  in  verification  is  identical  to  that  defined  in  Figure  3-8,  and  the  log  state¬ 
ments  were  physically  removed  from  the  output  of  an  enactment  run.  Thus  there  is  complete 
consistency  between  the  enactment  model  and  the  verification  model.  It  should  be  noted  that, 
while  we  have  not  discussed  automatic  generation  of  the  rules  for  a  verification  model,  such 
automation  could  be  performed  using  a  mapping  quite  similar  to  that  shown  in  Table  3. 


5.4  Implications  for  Verification 


The  exploratory  work  described  above  has  some  significant  implications.  These  fall  under  the 
main  headings  of  software  quality  and  process  certification,  configuration  management,  tool 
integration,  user  interaction,  metrics  and  finally,  process  improvement.  These  are  briefly 
discussed  below. 


•  Software  quality  and  process  certification.  On  completion  of  a  project,  a 
verification  analysis  can  formally  be  made  to  assure  that  all  steps  have  been 
completed  and  that  they  have  been  completed  in  the  right  order.  Such  formal 
verification  may  have  implications  for  contractor  process  certification  and  the 
ISO  9000  standard  [Kalinosky  90]. 

•  User  Interaction.  As  discussed  in  the  introduction,  a  major  concern  in 
enforcing  effective  process  is  the  imposed  restrictions  which  software 
developers  feel  either  from  a  supervisor,  or  from  an  automated  environment. 
The  approach  to  verification  in  no  way  restricts  the  manner  in  which  work  is 
accomplished  in  terms  of  detailed  oversight.  It  only  requires  that,  when  the 
project  is  completed  at  least  one  consistent  path  through  the  agreed  upon 
process  has  been  taken,  or  if  deviations  from  the  defined  path  have  been 
taken,  they  can  be  justified. 

•  Process  Improvement  and  metrics.  Throughout  a  project  which  uses 
process  verification,  significant  quantities  of  historical  data  will  be  gathered. 
This  data  can  be  used,  along  with  like  data  from  other  projects,  for  long-term 
process  improvement.  Data  from  each  project  can  be  analyzed  to  identify,  for 
example,  where  bottlenecks,  inefficiencies,  and  inaccurate  estimates  occur. 
By  having  formally-defined  process  models  and  data  from  their  enactment, 
considerable  insight  can  be  thus  obtained.  This  provides  all  the  necessary 
ingredients  for  both  qualitative  and  quantitative  process  improvement. 
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6  User-Oriented  Issues  with  PCDEs4 


The  previous  sections  have  dealt  primarily  with  technically-oriented  issues  associated  with  au¬ 
tomating  software  production.  However,  implementing  a  process-centered  development  envi¬ 
ronment  involves  much  more  than  just  addressing  the  technology.  Indeed  the  success  of 
adoption  rests  at  least  as  heavily  on  personnel,  organizational  and  cultural  elements.  This  sec¬ 
tion  thus  looks  briefly  at  a  variety  of  more  user-oriented  problems  facing  organizations  wishing 
to  adopt  a  PCDE.  Many  of  these  issues  are  also  relevant  to  software  development  environ¬ 
ments  in  general. 

A  significant  fraction  of  software  today  becomes  “shelfware”  [Page  92],  in  part  because  it  may 
not  meet  users’  functional  requirements,  because  of  lack  of  appropriate  user  training,  or  be¬ 
cause  of  lack  of  compatibility  with  the  project's  process.  Other  elements  may  also  contribute. 
[Boone  91]  discusses  factors  which  have  been  impediments  to  the  successful  introduction  of 
CASE  technology.  Such  factors  include  the  difficulty  which  developers  have  in  adapting  to  the 
different  philosophy  which  CASE  tools  impose  upon  them,  and  the  discomfort  which  manag¬ 
ers  have  when  coding  doesn’t  begin  until  much  later  in  the  development  cycle.  These  changes 
in  working  habits  will  only  be  magnified  when  complex  PCDEs  are  introduced. 

A  PCDE  will  be  costly  to  install,  in  terms  of  the  initial  investment  in  software,  in  terms  of  the 
required  training,  and  in  terms  of  its  adaptation  to  the  needs  of  the  projects  using  it.  There  will 
also  be  financial  and  technical  investments  in  its  long-term  maintenance.  The  likelihood  of  fail¬ 
ure  in  using  such  a  system  will  be  higher  than  with  individual  prooucts.  Given  the  high  cost  of 
this  kind  of  investment,  an  organization  may  shy  away  from  making  more  than  one  attempt  at 
installing  a  PCDE  if  the  first  attempt  is  perceived  as  a  failure.  However,  using  an  approach 
which  relies  heavily  on  graphical  support  for  process  definition,  process  enactment,  user  inter¬ 
face,  and  process  maintenance  will  increase  the  likelihood  of  success  of  such  systems. 

In  order  to  develop  an  effective  PCDE,  a  review  of  some  relevant  user-oriented,  adoption  and 
technology  transition  issues  is  thus  appropriate.  These  issues  are  the  subject  of  the  rest  of  this 
section. 

6.1  The  Application  of  Automated  Support 

If  not  designed  properly,  automated  support  may  get  in  the  way  rather  than  help.  Automating 
a  process  just  because  the  technology  exists  can  be  like  building  a  radar-activated  mouse  trap 
-  it  is  too  complex,  too  costly,  and  does  not  meet  the  user’s  simple  needs.  What  should  be 
automated?  First,  it  is  clear  that  automating  those  processes  that  are  well  understood  (i.e.,  de¬ 
fined)  makes  sense.  Thus  islands  of  automation  may  be  established,  with  the  later  possibility 
of  building  bridges  between  these  islands.  Second,  tasks  that  are  tedious  should  be  automat¬ 
ed,  thus  allowing  the  developer  to  concentrate  on  the  more  creative  aspects  of  the  job.  Third, 


4  Parts  of  this  section  have  been  adapted  from  an  article  appearing  in  lOPener,  Volume  1  No.  5.  November,  1992. 
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tasks  where  manual  involvement  frequently  introduces  error  should  be  candidates  for  automa¬ 
tion. 

Areas  where  automation  can  be  of  significant  help  include  configuration  management  (CM), 
change  tracking  and  metrics.  Others  include  code  reviews,  document  reviews,  requirements 
management  and  project  management.  Today  CM  is  already  well  automated  and  certain  CM 
tools  [e.g.,  CaseWare  92]  increasingly  allow  for  a  customized  process  to  be  defined  by  the 
end-user.  Much  work  still  needs  to  be  done  in  examining  the  overlap  between  CM  and  pro¬ 
cess,  but  systems  like  ISTAR  [Dowson  86]  and  others  [Bernard  89,  Mahler  90]  have  investi- 
B  ited  this  topic.  Process  models  can  provide  insight  into  what  artifacts  should  be  placed  under 
CM  control  ana  what  process  metrics  should  be  gathered.  In  the  CM  case,  our  simple  process 
model  provides  some  guidance.  In  a  well-formed  model,  those  artifacts  which  connect  activi¬ 
ties  to  activities  are  candidates  for  CM  control.  Thus,  both  product  versions  and  condition  ver¬ 
sions  should  be  placed  under  configuration  management.  In  this  context,  tracking  condition 
versions  allows  us  to  roll  back  in  time  to  any  prior  part  of  the  process  and  reconstruct  what  has 
occurred.  This  process  data  may  best  be  maintained  in  a  data  structure  similar  to  the  log  state¬ 
ment  of  our  process  enaction  notation.  The  required  process  information  also  provides  guid¬ 
ance  on  what  metrics  should  be  gathered  from  a  process  point  of  view.  This  information  is 
similar  to  the  CM  information  just  discussed. 

Not  only  must  process  models  be  sufficiently  flexible  to  account  for  a  wide  variety  of  scenarios, 
but  they  must  also  allow  for  the  adaptation  of  existing  scenarios.  Process  modification  can  take 
place  in  at  least  in  two  ways:  1)  as  part  of  a  process  improvement  effort,  or  2)  “on  the  fly”  while 
in  the  middle  of  a  project.  The  former  is  based  on  a  long-term  strategy,  supported  by  metrics 
gathering  and  analysis,  and  implemented  through  process  redesign  and  verification.  While  this 
is  challenging,  with  sufficient  lead-time  the  inherent  risks  can  be  minimized.  However,  real¬ 
time  modifications  to  an  on-going  process  contain  significant  risk.  Nevertheless  such  changes 
may  have  to  be  made  for  a  variety  of  reasons.  For  example,  the  process  may  not  be  perform¬ 
ing  as  expected  (i.e.,  it  was  not  adequately  debugged),  or  as  mentioned  earlier,  circumstances 
such  as  new  schedule  constraints  may  force  process  changes.  With  a  manually  implemented 
process,  changes  can  be  made  on  an  informal  basis.  However,  if  the  process  is  automated, 
the  ability  to  adapt  the  process  may  be  significantly  restricted. 

Process  support  tools  must  therefore  have  the  flexibility  to  support  rapid  process  modification. 
Tools  to  support  such  needs  as  graphical  process  definition,  automatic  translation  of  graphi¬ 
cally  defined  process  to  enactable  form,  verification  of  the  completeness  and  correctness  of 
the  process  model,  or  part  of  it,  and  process  simulation  capability  will  be  very  useful  in  this  re¬ 
gard.  These  tools  will  of  course  also  be  of  significant  help  in  long-term  process  improvement 
efforts.  Finally,  it  may  be  necessary  to  design  these  tools  so  that  a  project  can  degrade  grace¬ 
fully  into  manual  process  control  if  the  automated  mode  does  not  perform  adequately. 

i 
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6.2  Organizational  Factors 

A  PCDE  must  consider  the  needs  of  multiple  roles,  such  as  upper  management,  project  man¬ 
agement,  and  technical  development.  Each  of  these  roles  has  different  support  and  informa¬ 
tion  requirements;  in  general  lower  levels  in  the  hierarchy  will  support  the  higher  levels.  For 
example,  developers  will  provide  their  project  management  with  technical  and  status  informa¬ 
tion  related  to  tasks.  Metric  information  may  or  may  not  be  gathered  automatically  for  manage¬ 
ment  review  and  analysis.  In  addition,  planning  and  schedule  information  will  flow  from  project 
managers  to  upper  management.  A  PCDE  must  have  an  understanding  of  entities  such  as  ac¬ 
tivities,  roles,  products  and  of  the  relationships  connecting  those  entities.  Information  about 
the  entities  and  relationships  should  be  reflected  in  the  data  objects  underlying  the  environ¬ 
ment. 

Because  process  support  environments  are  likely  to  be  large  and  relatively  complex,  they  ere 
most  appropriate  for  large  structured  organizations  involved  with  major  software  systems.  For 
such  organizations,  having  common  data  schemas  is  important  for  communications,  project 
integration,  metrics  gathering  and  for  process  improvement.  Hence  it  seems  appropriate  that 
these  schemas  should  be  defined  at  the  organizational  level.  For  similar  reasons,  defining  a 
user  interface  that  is  as  consistent  as  possible  is  appropriate  at  this  level.  Different  technical 
departments  within  an  organization  will  need  different  tool  sets  and  may  use  processes  tai¬ 
lored  to  their  specific  needs.  Hence,  specification  of  tools  sets  and  department-specific  pro¬ 
cesses  may  be  needed  at  a  lower  level  of  organizational  granularity. 

6.3  Process  Needs  of  Managers  and  Developers 

In  general,  project  management  needs  will  include  the  ability  to  access  information  such  as 
quality  assurance  reports,  test  reports  and  status  reports  on  products  and  tasks.  On  the  oasis 
of  this  information,  the  manager  can  make  decisions  on  future  courses  of  action.  These  deci¬ 
sions  set  broad  constraints  on  how  developers  perform  their  technical  work.  The  means  of  im¬ 
posing  management  decisions  on  technical  personnel  should  be  through  a  well-defined 
process;  that  is,  the  developers  should  understand  the  ground  rules  within  which  they  can  per¬ 
form  their  work.  This  may  be  called  the  defined  management  process  and  is  an  enabling 
mechanism  for  a  productive  working  environment. 

While  the  manager’s  view  of  process  tends  to  be  one  of  control,  the  developer  s  view  is  one 
of  support.  Developer’s  processes  are  related  to  product  development  and  involve  such  activ¬ 
ities  as  design,  development,  and  testing  of  software  products  [Humphrey  92];  they  are  thus 
quite  different  from  management  processes.  The  developer  wishes  to  use  automated  process 
support  to  provide  guidance  when  it  is  requested  and  relieve  menial  chores  when  possible. 
Automated  process  support  tools  need  to  provide  a  sufficiently  broad  range  of  functionality  to 
express  these  different  needs.  One  area  where  automated  support  is  critical  is  metrics  collec¬ 
tion,  since  developers  may  be  reluctant  to  invest  time  in  an  activity  that  they  may  perceive  to 
be  of  primary  benefit  to  management. 
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Within  these  two  extremes,  there  is  a  third  category  of  process.  In  larger  projects,  groups  of 
developers  must  cooperate  [Ellis  91]  in  product  development.  In  this  case,  a  cooperative  pro¬ 
cess  should  be  defined  which  involves  aspects  of  both  support  for  and  control  of  products. 
Clearly,  when  multiple  developers  participate  closely  in  a  task,  issues  of  control  at  the  devel¬ 
oper  level  must  also  be  addressed.  At  a  minimum,  configuration  management  processes  are 
important  here  [Dart  91].  In  the  future,  special  tools  vhich  allow  developers  to  interact,  for  ex¬ 
ample  in  concurrent  debugging  [Dewan  93]  may  become  more  prevalent.  Thus  the  potential 
influence  of  groupware  products  in  PCDEs  needs  to  be  investigated. 

If  a  software  technology  does  not  meet  the  user’s  needs,  it  will  not  be  accepted.  In  a  similar 
way,  if  a  PCDE  is  not  well  adapted  to  the  way  people  work  and  interact,  it  is  likely  to  be  sub¬ 
verted.  By  enforcing  rigid  conventions  on  the  software  process,  an  automated  environment 
may  not  only  take  away  the  feeling  of  personal  control  but  may  prevent  a  developer  from  show¬ 
ing  initiatives  that  improve  efficiency.  For  example,  in  a  rigidly  automated  process,  a  developer 
may  be  unreasonably  prevented  from  initiating  a  subsequent  task  because  an  earlier  task  has 
not  been  completed.  Thus,  either  the  level  of  granularity  of  the  modeled  process  was  too 
coarse  (i.e.,  there  was  insufficient  resolution  to  account  for  small  tasks),  or  it  was  too  intrusive 
(it  should  not  even  have  attempted  to  control  tasks  in  this  way).  Section  4.5  suggests  an  alter¬ 
native  solution  to  this  problem. 

Automation  should  primarily  liberate  the  software  development  team  from  chores  which  can 
be  automated  (e.g.,  configuration  control,  gathering  of  metrics).  Second,  it  should  enforce  pro¬ 
cess  in  a  broad  sense  i.e.,  provide  a  framework  into  which  individual  processes  can  operate 
with  significant  freedom.  Other  constraints  are  probably  appropriate  for  specific  projects,  but 
in  adding  them,  a  trade-off  between  the  perceived  benefits  (productivity,  management  control, 
etc.)  and  the  human  impact  of  the  constraint  should  be  carefully  assessed.  As  Humphrey 
[Humphrey  89]  states:  “[T]he  environment  should  provide  strict  enforcement  of  liberal  pro¬ 
cess."  Humans  can  be  very  creative  in  circumventing  systems  which  do  not  support  their 
needs. 


6.4  Adapting  the  Process  to  Unforeseen  Circumstances 

Producing  a  computer  program  with  an  effective  understanding  of  user-oriented  process  is  a 
challenge.  Like  all  knowledge-based  computer  models,  process  programs  rely  on  reasoning 
(for  example,  rule-based  or  state-transition-based)  which  explicitly  takes  into  account  only 
specified  and  understood  changes  in  the  system  behavior.  While  a  well-regulated  process  will 
have  a  significant  degree  of  predictability;  unaccounted  circumstances  may  occur.  These  are 
much  more  difficult  to  handle  within  an  automated  environment. 

The  problem  of  what  mental  models  humans  apply  to  particular  situations  is  one  which  the 
Danish  industrial  psychologist  Jens  Rasmussen  has  addressed.  He  perceives  three  levels  of 
cognitive  abstraction.  At  the  lowest  level  there  is  the  reflexive  “if  this  happens...then  do  that” 
reasoning  that  is  applied  under  normal  conditions.  This  he  calls  the  "skill”  level.  Computers 
modeling  this  level  have  shown  significant  success  using,  for  example,  expert  systems.  At  a 
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second  level,  the  expert  may  have  to  rely  on  past  experiences  to  reason  about  a  condition 
which  is  not  normally  encountered;  from  these  past  experiences  he  will  then  formulate  a  plan. 
An  example  might  be  how  to  modify  the  process  if  a  hard  deadline  is  approaching.  This  Ras¬ 
mussen  calls  the  “rule”  level;  while  amenable  to  computer  analysis,  this  is  more  challenging 
than  the  skill-based  regime.  Finally  the  expert  may  encounter  an  altogether  new  situation 
where  reasoning  from  first  principles  is  required.  Examples  of  this  might  be  loss  of  critical 
project  data  through  natural  disaster  or  because  of  a  virus-infected  repository.  This  Rasmus¬ 
sen  calls  the  “knowledge”  level;  this  level  probably  requires  complete  human  intervention. 

These  examples  indicate  how  the  human  expert  modifies  reasoning  levels  according  to  on  the 
complexity  and  novelty  of  the  situation  [Rasmussen  79].  It  is  difficult  to  build  this  kind  of  flexi¬ 
bility  in  reasoning  into  a  software  system.  This  is  not  to  say  that  automating  the  process  is  in¬ 
appropriate,  rather  that  the  limitations  must  be  understood.  Addressing  the  limitations  of 
PCDEs  may  mean,  for  example,  that  they  should  have  the  facility  to  be  modified  “on  the  fly” 
(so  that  incidents  at  the  “rule”  level  can  be  accommodated),  and  should  be  designed  to  grace¬ 
fully  degrade  to  a  manual  process  (so  that  incidents  at  the  “knowledge"  level  can  be  accom¬ 
modated). 

6.5  Lessons  from  Groupware 

Human-computer  interaction  has  been  extensively  analyzed  by  people  in  the  field  of  comput¬ 
er-supported  cooperative  work  (CSCW)  [Ellis  91].  The  products  deve>  v;~<;  (usually  called 
groupware)  are  aimed  at  supporting  teams  of  people  who  use  networked  computers  to  facili¬ 
tate  joint  efforts.  Generally  groupware  supports  three  functional  categories:  communication, 
collaboration,  and  coordination.  A  common  example  of  a  communication  package  is  e-mail; 
an  example  of  a  collaboration  package  might  be  an  editor  that  allows  simultaneous  update 
from  multiple  terminals;  an  example  of  a  coordination  package  might  be  a  group  scheduler. 
Most  of  these  tools  are  of  a  generic  nature  to  support  non-technical  or  management  goals. 
However,  because  they  have  to  deal  with  how  humans  interact  in  tightly  coupled  settings,  re¬ 
search  in  this  field  offers  insights  into  issues  relevant  to  the  process  constraints  on  environ¬ 
ments. 

Within  the  context  of  PCDEs,  there  are  several  areas  where  groupware  technology  is  likely  to 
be  important: 

•  specification/design 

•  documentation 

•  code  inspections 

•  project  planning 

•  reviews  (e.g.,  of  change  requests) 

Some  of  the  above  (e.g.,  code  inspections)  are  truly  synchronous  activities,  that  is,  the  group 
participates  at  the  same  time,  either  at  different  terminals  at  the  same  location  or  geographi¬ 
cally  dispersed.  In  others  (e.g.,  documentation)  the  mode  of  interaction  is  more  likely  to  be 


CMU/SEI-93 -TR-4 


45 


asynchronous.  Some  lessons  learned  from  groupware  evaluations  which  bear  on  softer  e 
PCDEs  are: 

•  Don't  try  to  get  too  elaborate  with  sophisticated  functionality.  Instead  focus 
on  a  system  which  emphasizes  basic  functionality  and  ease  of  access  and 
does  these  well  from  a  user  point  of  view. 

•  If  non-electronic  analogies  or  metaphors  can  be  used  to  describe  entities/ 
attributes,  use  them. 

•  The  system's  architecture  should  be  designed  from  the  beginning  to  reflect 
seamless  data  and  control  integration.  The  difference  between  a  system 
where  one  can  move  effortlessly  between  applications  and  one  where  such 
movement  is  awkward  can  be  crucial  to  success. 

•  Be  careful  in  adding  features  which  may  have  advantages  for  one  group 
while  imposing  the  work  on  another  group.  (This  is  the  “what's  in  it  for  me?” 
syndrome.) 

•  Don't  try  to  over-automate  the  process  as  all  possible  configurations  that  the 
system  may  encounter  cannot  be  predicted.  The  need  for  manual  control 
over  process  execution  will  therefore  be  necessary. 

•  Design  the  environment  for  changing  requirements.  Human  needs  are  very 
difficult  to  predict,  and  the  system  must  be  adaptable  to  account  for  user 
experience. 

These  points  are  also  discussed  in  [Bull  90.  Grud  88,  Sing  91]. 

6.6  Configuration  Management,  Conflict,  and  Cooperation 

Those  aspects  of  ProNet  dealing  with  1)  versioned  products  or  conditions  and  2)  the  put  and 
get  commands,  allow  the  notation  to  explicitly  model  some  basic  configuration  management 
operations.  In  CM  terms,  put  and  get  correspond  to  check-in  and  check-out.  Currently,  oper¬ 
ations  such  as  branch  and  merge  have  not  been  not  addressed,  nor  has  the  ability  to  lock  the 
store  after  a  product  has  been  checked  out.  At  a  minimum,  a  locking  mechanism  could  be  add¬ 
ed  to  the  notation  with  little  difficulty.  However,  to  be  fully  responsive  to  users,  any  realistic  pro¬ 
cess  enactment  language  needs  to  go  beyond  simple  locking. 

In  any  practical  PCDE,  the  ability  to  handle  products  within  a  cooperative  group  environment 
could  be  important,  particularly  at  the  software  development  level.  Currently  configuration 
management  tools  do  support  cooperative  development.  For  example,  tools  such  as  SHAPE, 
SMS,  and  NSE  provide  isolated  workspaces,  and  the  ability  to  resolve  conflicts  when  merges 
are  made  between  workspace  product  versions  and  the  public  repository  [Dart  91].  In  partic¬ 
ular,  NSE  [Feiler  90]  provides  for  multiple  workspaces.  Each  workspace  can  have  a  virtual 
copy  of  the  original  parent  environment;  only  when  a  file  is  checked  out  in  the  workspace  is  a 
physical  copy  of  it  made.  If  files  in  the  parent  environment  have  been  updated  by  one  devel¬ 
oper,  then  modifications  from  another  developer  (one  who  has  also  removed  a  copy  of  the  un¬ 
modified  parent)  cannot  be  merged  into  the  environment.  The  second  developer  must  perform 
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a  local  merge  of  the  files  and  debug  the  two  sets  of  changes  before  updating  the  parent  envi¬ 
ronment. 

The  above  approach  to  parallel  development  does  relax  the  constraint  that  development  is 
strictly  serial.  However,  it  still  does  not  support  dose  cooperative  development.  For  example, 
two  persons  may  not  be  able  to  work  in  an  interactive  way  on  a  section  of  code.  As  stated  in 
[Bargouti  90], 

Having  the  development  process  explicitly  encoded  does  not  alone  solve  the 
problem  of  supporting  multiple  users,  a  requirement  for  any  large-scale  soft¬ 
ware  development  effort.  The  basic  problem  is  the  inability  to  allow  concurrent 
access  to  project  components  while  still  maintaining  the  consistency  of  these 
components. 

The  above  issues  of  concurrency  and  synchronization  have  been  addressed  neither  within  the 
ProNet  modeling  language  nor  in  its  enactable  form.  However,  work  which  investigates  graph¬ 
ical  modeling  in  these  areas  is  discussed  by  [Singh  92]  using  a  role-centered  approach  sup¬ 
ported  by  Petri  Nets.  Such  work  may  help  illuminate  some  of  the  problems  associated  with 
developing  enactable  PCDE  specifications  when,  for  example,  close  developer  cooperation 
is  required. 
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7  Summary  and  Conclusions 


This  report  has  explored  a  variety  of  issues  at  the  intersection  of  process  definition,  process 
enactment,  and  process  verification.  The  central  focus  has  been  to  describe  a  unified  ap¬ 
proach  to  these  topics.  It  was  suggested  that  construction  of  a  process-centered  development 
environment  should  be  preceded  with  the  development  of  a  graphically-based  specification  of 
the  process  to  be  automated.  This  specification  should  not  only  be  graphically  based,  but 
should  allow  for  automatic  compilation  into  an  enactable  form.  The  reasons  for  having  such  a 
graphical,  enactable  specification  are  five-fold: 

•  The  enactable  specification  allows  a  PCDE  to  be  validated  through  dynamic 
simulation  and  logical  analysis  prior  to  its  construction.  This  approach  will  be 
much  less  costly  than  developing  and  debugging  a  fully-fledged  PCOE  using 
other  approaches. 

•  Any  real-world  software  development  process  will  exhibit  significant 
complexity.  This  process  needs  to  be  understood  by  all  interested  parties, 
from  the  managers  who  sign  off  on  its  acceptability  to  the  personnel  who  will 
use  it.  If  the  only  people  who  understand  the  language  in  which  the  process 
is  defined  are  the  process  "gurus,”  then  it  is  unlikely  to  be  adopted.  This  buy- 
in  is  critical  to  success. 

•  The  ability  of  the  organization's  members  to  discuss  the  process  and  to 
suggest  improvements  or  “bug  fixes”  will  depend  on  their  understanding  of 
the  process.  This  will  be  helped  significantly  if  the  process  is  documented 
graphically. 

•  The  graphical  representation  will  be  of  considerable  help  to  new  employees 
as  they  learn  the  elements  of  their  jobs  and  how  their  jobs  relate  to  other 
activities. 

•  A  record  of  the  history  of  the  process  improvement  efforts  can  be  captured 
automatically  through  the  use  of  graphical  process  descriptions. 

A  graphical  process  notation  was  introduced  (Section  3)  which  exhibits  many  of  the  needed 
characteristics  for  process  definition.  This  rotation  accounts  for 

•  the  agents,  roles,  artifacts,  and  activities, 

•  control  flows  and  product  version  management,  and 

•  hierarchical  nesting  of  models. 

To  investigate  issues  associated  with  enactment,  the  ProNet  notation  was  used.  Fortunately, 
this  graphical  notation  is  appropriately  structured  for  translation  into  an  enactable  form.  Exam¬ 
ples  of  how  different  graphical  process  elements  can  be  mapped  to  corresponding  symbolic 
forms  was  provided  in  Section  4.  This  mapping  was  done  by  hand  and  used  the  example  of  a 
change  request  process.  However,  as  was  shown,  a  well-defined  set  of  rules  exists  whereby 
the  mapping  could  be  automated.  The  symbolic  form  is  declarative  and  implemented  in  Prolog. 
It  results  in  a  production  system  in  which  each  of  the  activities  in  the  process  model  translates 
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into  a  rule.  These  rules  are  managed  by  a  “process  driver”  which  allows  for  process  interaction 
with  the  user.  The  actual  program  is  listed  in  Appendix  A. 

Process  verification,  as  defined  here,  is  a  post-analysis  of  process  data  gathered  during 
project  execution  (down  to  an  appropriate  level  of  granularity).  This  was  discussed  in  Section 
5.  The  object  of  verification  is  to  determine  if  a  subset  of  all  the  activities  that  have  been  per¬ 
formed  and  products  that  have  been  produced  conform  to  the  prescribed  process.  With  pro¬ 
cess  automation  in  place,  gathering  process  data  is  essential  (otherwise  the  system  does  not 
know  what  needs  to  be  performed  next).  Thus  the  data  needed  for  verification  comes  at  no 
extra  charge.  If  a  project  strictly  adheres  to  the  defined  process  during  process  execution,  then 
the  data  should,  by  definition,  be  valid.  However,  in  real  situations  manual  interventions,  which 
may  compromise  strict  adherence  to  the  defined  process,  are  likely.  Thus  the  verification  pro¬ 
cedure  provides  a  final  assurance  that  the  process  has  been  followed.  It  was  found  that  a  sym¬ 
metry  between  process  enactment  and  verification  exists.  While  enactment  moves  f onwards 
in  time  and  generates  a  trace  of  the  process  history,  verification  starts  at  the  end  and  works 
backwards  in  time,  consuming  the  trace  generated  by  the  enactment  activity.  The  program  by 
which  process  verification  was  investigated  is  provided  in  Appendix  B. 

In  Section  6  we  addressed  a  wide  spectrum  of  issues  related  to  the  use  of  PCDEs.  We  started 
out  by  reviewing  areas  that  are  good  candidates  for  process  automation,  and  discussed  rea¬ 
sons  why  the  associated  process  models  should  be  built  with  flexibility  in  mind.  We  then 
looked  at  some  organizational  issues  related  to  1)  information  flows  between  developers, 
project  management  and  upper  management,  and  2)  the  need  for  the  consistency  of  both  data 
structures  and  user  interface  across  projects.  The  different  needs  of  developers  and  manag¬ 
ers  was  then  addressed;  how  developers  desire  a  PCDE  to  support  their  development  needs 
while  managers  desire  a  PCDE  to  provide  mechanisms  for  project  control  and  information  ac¬ 
cess.  It  was  noted  that  both  groups  have  a  common  need  for  a  PCDE  to  alleviate  chores.  We 
then  moved  on  to  discuss  models  of  problem  solving  and  how  a  PCDE  must  be  have  the 
adaptability  to  address  unexpected  process-related  problems.  This  was  related  to  the  work  of 
Jens  Rasmussen.  Of  increasing  importance  in  large  projects,  is  cooperative  development  in 
communication,  collaboration  and  coordination.  This  field  is  generally  referred  to  as  “group- 
ware”  and,  because  of  its  increasing  importance  to  software  development,  was  also  reviewed. 
Finally,  it  was  noted  than  any  PCDE  which  satisfies  the  needs  of  software  developers  working 
in  a  cooperative  arena  should  include  notions  on  configuration  management,  concurrency  and 
synchronization. 

It  is  hoped  that  this  report  has  shed  some  light  on  issues  which  need  to  be  addressed  before 
process  enactment  becomes  a  practical  and  successful  reality.  Clearly,  PCDE  developers  will 
have  to  focus  increasingly  on  process,  first  with  respect  to  the  usability  of  their  products  and 
second  with  respect  to  the  impact  process  modeling  and  enactment  concepts  will  make  on 
current  software  development  environments. 


so 
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Appendix  A  The  Process  Enactment  Program 

Appendix  A  provides  information  on  the  Prolog  program  which  demonstrates  simple  process 
enactment.  Section  A.1  first  illustrates  typical  output  from  the  program.  The  program  (Section 
A.2)  is  self-contained  and  does  not  require  any  input  other  than  the  requested  name  of  the 
user  and  the  activity  that  the  user  has  selected  (as  seen  in  Section  A.1 ).  Section  A.3  provides 
a  modification  to  the  program  to  show  how  hierarchical  nesting  of  activities  may  be  implement¬ 
ed.  All  program  listings  in  Appendices  A  and  B  were  developed  using  AIS  Prolog  [AAIS  90]  on 
the  Macintosh. 

A.1  Typical  Program  Output 

The  following  listing  illustrates  an  interactive  session  with  the  automated  process  controller. 
Once  the  user’s  name  is  entered,  the  controller  1 )  checks  the  validity  of  the  name,  2)  identifies 
the  roles  associated  with  this  name,  3)  finds  the  activities  which  can  next  be  performed  by  that 
role  and  then  4)  presents  the  available  activities  to  the  user.  The  user  selects  the  next  activity 
to  be  performed.  Clearly  at  this  point  the  process  controller  must  communicate  with  the  tools 
(editor,  compiler,  etc.)  necessary  to  perform  the  task,  but  the  addition  of  such  functionality  is 
beyond  the  scope  of  this  investigation.  The  example  below  is  extracted  from  the  process  de¬ 
fined  in  Figure  3-8. 


What  ia  your  name:  alanC. 

Available  activities: 

actlO  get  CR  from  CR  repoa  -  for  update 
act 9  get  review  doc  from  doc  repos  -  for  update 

Enter  the  ID  of  the  activity  you  wish  to  perform:  actlO . 
get  CR  from  CR  repos  -  for  update  —  done 

************************************************** 

What  is  your  name:  susan. 

There  are  no  activities  currently  available  for  this  role. 


What  is  your  name:  alan. 

Nobody  by  that  name  or  no  designated  role 
abort?  (y/n)  :  n . 

What  is  your  name:  alanC. 

Available  activities: 

act9  get  review  doc  from  doc  repos  -  for  update 
Enter  the  ID  of  the  activity  you  wish  to  perform:  act9. 
get  review  doc  from  doc  repos  -  for  update  —  done 

************************************************** 


What  is  your  name:  alanC. 
Available  activities: 
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act 11  update  CR 

Enter  the  ID  of  the  activity  you  wish  to  perform:  actl2. 
act  12  —  is  not  in  the  activity  list. 

Available  activities: 
act 11  update  CR 

Enter  the  ID  of  the  activity  you  wish  to  perform:  actll. 
update  CR  —  done 

************************************************** 


A.2  The  Process  Controller  Listing 

The  following  Prolog  listing  is  for  the  process  controller.  An  overview  of  the  program's  func¬ 
tionality  is  described  in  Section  4.3. 

/*********************  process  initiator  **********************/ 
initProcess (InitEnt) : - 
initSystemVar s , 
initUserVars, 
makeNameLi st , 
assert (InitEnt) , 
doNext Act . 


/***********************  driver  functions  *********************/ 
doNextAct : - 

/*  sets  up  the  recursive  loop  for  each  activity  in  the  process  */ 
retractall (active (_) ) , 

write  (’**************************************************•) ,  nl,  nl, 

/*  get  the  agents ' a  name  and  check  if  it  exists  */ 
checkName (Role) , 

/*  find  activities  which  can  be  performed  next*/ 
f indActs (ActLiat) , 

/*  remove  these  activities  not  appropriate  for  this  role  */ 
delActs (Role,  ActLiat,  [),  ActListl), 

/*  select  the  activity  which  will  be  performed  */ 
ask (Role,  ActListl), 
doNextAct . 

f indActs (_) : - 

/*  test  all  activity  perconditions  to  find  currently  valid  activities  */ 
actRole (Test,  _,  _,  _) , 

TestX  -. .  (Tost) , 

TestX, 
fail . 

f indActs (ActList) :- 

/*  group  all  currently  valid  activities  into  a  list  */ 
bagof(Act,  active(Act),  ActList). 

f indActs (_) : - 

/*  no  activities  in  list  -  process  completed  */ 
write('All  activities  have  been  completed'),  nl, 
abort . 

nullActs  (  )  . 
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delActs (_,  [],  ActList,  ActList) . 

delActs (Role,  [Act  I ActList] ,  ActListl,  X)  :- 

/*  eliminate  these  activities  which  cannot  be  performed  by  current  role  */ 
active (Act) , 

actRole (_,  Act,  Role,  _)  , 

delActs (Role,  ActList,  [Act | ActListl ] ,  X). 

delActs (Role,  [Act  I ActList] ,  ActListl,  X) 

/*  eliminate  these  activities  which  cannot  be  performed  by  current  role  */ 
retract (active (Act) ) , 

delActs (Role,  ActList,  ActListl,  X). 
ask (_,  []) 

/*  present  user  with  options  */ 

write  ('There  are  no  activities  currently  available  for  this  role.'),nl,  nl, 
doNextAct . 

ask (_,  _) : - 

/*  present  user  with  options  */ 
write ( 'Available  activities:'),  nl, 
active (Act) , 

actRole (_,  Act,  _,  Text), 

write ('  '),  write (Act),  write ('  •),  write (Text),  nl, 

fail . 

ask (Role,  ActList) : - 

/*  present  user  with  options  */ 

write ('Enter  the  ID  of  the  activity  you  wish  to  perform:  '), 
read(ActlD) , 

next Act (ActID,  Role,  ActList). 

nextAct (abort,  _,  _) : - 
abort . 

nextAct  (ActID,  Role,  ActList) :- 

/*  activity  selected  is  illegal  */ 
not (member (ActID,  ActList)), 

write (ActID) ,  write ( '  —  is  not  in  the  activity  list.  '),  nl,  nl, 
ask (Role,  ActList). 

nextAct (ActID,  Role,  ActList) 

/*  activity  selected  is  illegal  */ 
not  (actRole (_,  ActID,  _,  Desc) ) , 

write  (Desc) ,  write ( '  —  cannot  be  performed  by  the  role:  '), 
write (Role),  nl,  nl, 
ask (Role,  ActList). 

nextAct (ActID,  _,  _):- 

/*  perform  activity  selected  by  user  */ 

ActX  -. .  [ActID] , 

ActX. 

initSystemVars : - 

/*  clear  program  of  all  garbage  left  from  previous  run  */ 

retractall (ver (_,_) ) , 

asserta (ver  (0, 0) ) , 

retractall (log(_,_,_) ) , 

asserta (log  (nul,nul,nul) ) , 
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retractall (subact (_) ) , 
retractall (nameList (_) )  , 
retractall (actList) . 


/****.******.**.*.******  utility  functions  *******************»*/ 
set (X, K) 

/*  initialize  version  number  X  to  value  K  */ 
retractall (ver (X, _) ) , 
assert (ver (X, K) ) . 

inc  (K) : - 

/*  increment  version  number  K  by  1  */ 
retract  (ver (K, J) ) , 

J1  is  J+l, 
assertz (ver  (K,  Jl)  )  . 

put_ent (Store,  Val,  OutList):- 

/*  put  an  entity  into  a  store  and  assert  exit  entities  */ 

testfor_(Val, Vail) , 

retract (store (Store,  Val_list)), 

assertz (store (Store,  [Vail | Val_list ] ) ) , 

assertList (OutList) . 

assertList ( ( ] ) . 

assertList ( [First | Rest] ) : - 
assert (First) , 
assertList (Rest) , 

get_ent (Store,  Val) : - 

/*  retrieve  an  entity  from  a  store  */ 

testfor_(Val,  Vail), 

store (Store,  Val_list) , 

member (Vail ,  Val_list) , 

assertz (Val) . 

get_ent (Store,  Val):- 

/*  retrieve  an  entity  from  a  store  -  entity  not  found  */ 
write (Val) , 

write ('  is  not  contained  in  '), 
write (Store) , nl , 

i 

•  f 

abort . 

testfor_(Val,  Vail) 

/*  remove  digit  from  end  of  entity  name  -  if  entity  has  one  */ 

Val  [Name, Var]  , 

explode (Name,  CharsList) , 

reverse (CharsList,  [Last  I  List] ) , 

string(Last,  Str) , 

int2string  (Int,  Str), 

integer (Int) , 

reverse  (List,  Listl), 

explode (Namel ,  Listl), 

Vail  .  [Namel,  Var] . 

testfor_ (Val ,  Val). 

decision (Docl , Doc2, Doc) 
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/*  needed  to  decide  between  two  paths  og  an  output  OR  */ 
random ( 10, Y) , 

(Y  >  5,  Doc-Doc 1;  Doc-Doc2) . 

random (R,N) 

retract (seed<S) ) , 

N  is  <S  mod  R)  +  1, 

NewSeed  is  (125*S+1)  mod  4096, 
assertz (seed (NewSeed) ) ,  ! . 

seed(13) . 

textOut (Act) : - 

/*  write  out  text  associated  with  an  activity  */ 

actRole(_,  Act,  _,  Text), 

write (Text),  write ( '  —  done'),  nl,  nl. 

makeNameList : - 

/*  make  a  list  of  all  agent  names  */ 
hasRole (_,  Name)  , 
asserta (oneName (Name) ) , 
fail . 

makeNameList : - 

/*  make  a  list  of  all  agent  names  */ 
setof (Name,  oneName (Name) ,  Names) , 
retractall (oneName (_) ) , 
assert (nameList (Names) ) . 

checkName (Role) 

/*  enter  and  check  user  name  */ 

write ('What  is  your  name:  '), 

read (Name) , 

nameList (Names) , 

member (Name,  Names), 

hasRole (Role,  Name). 

checkName (_) : - 

/*  invalid  user  name  */ 

write  ( '  Nobody  by  that  name  or  no  designated  role'),  nl, 
write ( ' abort?  (y/n) :  ' ) , 
read( 'n' ) ,  nl, 
checkName (_) . 

checkName (_) : - 
abort . 

/*********************  activity  entrance  conditions  ***************************/ 
/***  these  are  all  tested  against  at  each  cycle  to  current  activities  ***/ 
testl : - 

? (intern_prob_iden) , 

not (log (devel_intern_cr,  _,  [cr_intern] ) ) , 
asserta (active (actl) ) . 

test2 : - 

?  (extern_prob_iden)  , 

not  (log (devel_extern_cr,  _,  ( f ield_cr J ) ) , 
asserta (active (act2) ) . 
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teat3 : - 

? (f ield_cr) , 

not (log (e-mail_cr,  [cr_extern] )) # 

asserta (active  (act3) ) . 

test4 :  - 

(? (cr_intern) ;  ? (cr_extern) ) , 
not (log (f ormat_cr ,  [crl(l)])), 

asserta (active  (act  4 ) )  . 

teatS : - 
ver  (k,K) , 

?<crl  (K) > , 

not (log (put_into_repos_A,  [cr_added(K) ] ) ) , 

asserta (active (act5) ) . 

test6 : - 
ver (k,K) , 

? (cr_added(K) > , 

not (log (get_f rom_repos_A,  [cr2 (K) ] ) ) , 

asserta  (active  (act6) ) . 

test? : - 
ver (k,K) , 

?<cr2 (K)>, 

not (log (review_cr,  (cr_appr] ) ) , 

not (log (review_cr,  [rev_docl (K) ] ) ) , 

asaerta (active (act7) ) . 

test8 : - 
ver (k,K) . 

? (revdocl (K) ) , 

not (log (put_into_repos_B,  ( rev_doc_addedl  (K) ,  rev_doc_added2  (K) ] ) ) , 
asserta (active (act8) ) . 

teat9 : - 
ver (k,K) , 

? (rev_doc_addedl  (K) ) , 

not (log (get_f rom_repoa_B,  [rev_doc2 (K> ] ) ) , 
asaerta (active (act9) ) . 

teatlO: - 
ver (k,K) , 

? (rev_doc_added2 (K) ) , 

not (log (get_£rom_repos_C,  [cr3  (K) ] ) ) , 
asserta (active (actlO) ) . 

testl 1 :  - 
ver (k,K) , 

K1  is  K+l, 

? (cr3 (K) ) , 

? (rev_doc2 (K) ) , 

not (log (update_cr ,  (crl(Kl)])), 

asaerta (active (actl 1 ) ) . 

teatl2 :  - 
ver (k , K) , 

? (act7in(K) ) , 

not (log (read_cr ,  [cr_read (K) ] ) ) , 
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asserts (active (act!2) ) . 


testl3: - 
ver (k,K) , 

? (cr_read (K) ) , 

not (log (approve_cr,  [rev_docl (K) ] ) ) , 

not (log (approve_cr,  [cr_appr] > )  , 

asserta (active (actl3) ) . 


/*********•********  activities  and  exit  conditions  ********************/ 
actl : - 

assertz (log (devel_intern_cr,  [intern_prob_iden J ,  [cr_intern] ) ) , 
assert (cr_intern) , 
textOut (actl) . 

act2 : - 

assertz (log (devel_extern_cr,  [extern_prob_idenj ,  [field_cr] ) ) , 
assert (field_cr) , 
textOut  (act 2) . 

act3:- 

assertz (log (e-mail_cr ,  [f ield_cr]  ,  [cr_extern] ) ) , 
assert (cr_extern) , 
textOut (act3) . 

act 4 : - 

(? (cr_intern) ,  X-cr_intern;  ? (cr_extern) ,  X-cr_extern) , 
assertz (log (format_cr,  [X],  [crl(l)])), 

assertz (crl (1) ) , 
set (k,l) , 
textOut (act 4) . 

act5: - 

ver (k,K) , 

assertz (log (put_into_repos_A,  [crl(K)l,  [cr_added (K) ] ) ) , 
put_ent (cr_repos, crl (K) ,  [cr_added (K) ) ) , 
textOut (act5) . 

act 6 : - 

ver (k,K) , 

assertz (log (get_f rom_repos_A,  [cr_added (K) J ,  [cr2  (K) ] ) ) , 
get_ent (cr_repos,  cr2 (X)  ) , 
textOut (act6) . 

act 7 :  - 

ver (k,K) . 

decision (cr_appr, rev_docl (K) , Doc) , 
assertz (log (review_cr,  (cr2 (K) ] ,  [Doc])), 
assertz (Doc) , 
textOut  (act7) . 

act8: - 

ver  (lt,K)  , 

assertz  (log  (put_into_repos_B,[rev_docl  (K)  J  ,(rev_doc_addedl  (K)  ,rev_doc_added2  (K)  ] )  )  , 
putent (rev_doc_repos,  rev_docl (K) ,  [ rev_doc_addedl (K) ,  rev_doc_added2 (K) ) ) , 

textOut (act8) . 

act9 : - 
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ver  (k,K) , 

asaertz (log (get_f rom_repos_B,  [rev_doc_addedl (K) ] ,  [rev_doc2 (K) ) ) ) , 
get_ent (rev_doc_repos, rev_doc2 (K) ) , 
textOut (act 9) . 

act 10 : - 
ver (k,K) , 

asaertz (log (get_f rom_repos_C,  (rev_doc_added2 (K) ] ,  [cr3(K)])>, 

get_ent (cr_repos,  cr3 (K) ) , 
textOut (actlO) . 

act 11 : - 
ver (k,K) , 

K1  is  K+l , 

asaertz  (log (update_cr,  (cr3(K),  rev_doc2 (K) ) ,  [crl(Kl)))), 

asaertz  (crl (Kl) ) , 
textOut (act 11 ) , 
inc  (k)  . 

act  12 :  - 
ver (k, K) , 

assert (log (read_cr,  [cr2(K)],  [cr_read (K) ] ) ) , 
assert (cr_read (K) ) , 
textOut (act 12) . 
actl3 : - 
ver (k,K) , 

decision (cr_appr, rev_docl (K)  ,  Doc)  , 
asaertz (log (approve_cr,  [cr_read (K) ] ,  [Doc])), 
asserta (Doc) , 
textOut (act 13) . 


/*.**•*•*.«.*..********.  supporting  model  data  *********************/ 
actRole (testl ,  actl,  developer,  'initialize  internal  CR’). 
actRole (test2 ,  act2,  field_rep,  'initialize  external  CR'). 
actRole (test3,  act3,  field_rep,  'e-mail  external  CR’). 
actRole (test4 ,  act4,  developer,  'format  CR  for  repository'). 
actRole (test5,  acts,  developer,  'put  CR  revision  into  CR  repos’). 
actRole  (test6,  act6,  reviewer,  'get  CR  from  CR  repos  -  for  review'). 
actRole (test7,  act7,  reviewer,  'CR  review'). 

actRole (tests ,  act8,  reviewer,  'put  review  doc  into  doc  repos'). 

actRole (test9,  act9,  developer,  'get  review  doc  from  doc  repos  -  for  update'). 

actRole (testlO,  actlO,  developer,  'get  CR  from  CR  repos  -  for  update'). 

actRole  (testll,  actll,  developer,  'update  CR'). 

actRole (testl2,  actl2,  reviewer,  'read  CR'). 

actRole (testl3,  actl3,  reviewer,  'approve  CR'). 

/***********************  supporting  model  data  *********************/ 

hasRole (developer ,  ed) . 

hasRole (developer ,  paul). 

hasRole (developer ,  alanB) . 

hasRole (developer ,  alanC) . 

hasRole (reviewer,  susan). 

hasRole (reviewer ,  dennis) . 

hasRole (reviewer,  jock) . 

hasRole (developer,  mike). 

hasRole (reviewer,  cliff). 

hasRole \field_rep,  howard) . 

/****<****************•*  initialize  variables  *******************»*/ 
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initUserVars : - 

retractall (crl  (_) )  , 
retractall (cr2  (_)  ) , 
retractall (cr3  (_) ) , 
retractall (cr_added (_) )  , 
retractall (rev_docl  (_) )  , 
retractall (rev_doc2 (_) ) , 
retractall ( rev_doc_addedl (_) ) , 
retractall ( rev_doc_added2 (_) ) , 
retractall (cr_appr) , 
retractall (cr_read(_) ) , 
retractall (active (_) ) , 
retractall (intern_prob_iden)  , 
retractall  (extern__prob_iden)  , 
retractall (field_cr) , 
retractall (cr_intern) , 
retractall (cr_extern)  , 
asserta  (store (cr_repos,  [))), 
asserta  (store (re v_doc_repos ,  (1 ) )  . 


A.3  An  Extension  to  Account  for  Nested  Activities 

The  following  program  excerpts  modify  the  listing  of  Section  A.2  to  account  for  hierarchical 
nesting  of  activities.  The  changes  take  place  in  the  rules  and  not  the  process  driver  routines. 
The  activity  review_a  in  Figure  3-8  is  given  two  serial  sub-activities:  readja  and  approve_cr. 
The  resulting  process  fragment  is  illustrated  in  Figure  A-1 . 

/*************  modified  activity  'test'  clauses  *******************/ 
test7in:- 
ver  (k,K) , 

? (cr2 (K) ) , 

not (log (review_cr_in,  [act7in (K) ] ) ) , 
asserta (active (act7in) ) . 

test7out : - 
ver  (k,K) , 

? (cr_appr) ;  ? (rev_docl (K) ) , 

not (log (review_cr_out ,  [act7out (K) ] ) ) , 

assert (active (act7out) ) . 

test8 : - 
ver (k, K) , 

? (act7out  (K) ) , 

not (log (put_into_repos_B,  (rev_doc_addeal (K) ,  rev_doc_added2 (K) ] ) ) , 
asserta (active (act8) )  . 

/**»**«***♦**»  additional  activity  'test'  clauses  *******************/ 
testl2 :  - 
ver  (k, K) , 

? (act7in <K) ) , 

not (log (read_cr ,  ( cr_read (K) ] ) ) , 

asserta (active  (actl2) )  . 

testl3:  - 
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ver (k,K) , 

? (cr_read (K) ) , 

not (log (approve_cr,  _,  [rev_docl (K) ] ) ) , 
not (log (approve_cr,  [cr_appr])), 

asserta  (active  (actl'*'  )  . 

/*************  modified  activity  'act'  clauses  *******************/ 
act7in : - 
ver (k, K) , 

assertz (log (review_cr_in,  [cr2(K)],  [act7in  (K) ] ) ) , 
assert (act7in  (K) ) , 
textOut  (act7in) . 

act7out : - 
ver  (k , K) , 

(?(cr_appr),  X*cr_appr;  ? (rev_docl (K) ) ,  X-rev_docl (K) ) , 
assertz (log (review_cr_out,  [X],  [act7out (K) ] ) ) , 
assert (act7out (K) ) , 
textOut (act7out) . 

/*************  additional  activity  'act'  clauses  *******************/ 
actl2 : - 
ver  (k,K) , 

assert (log (read_cr,  (cr2 (K> ] ,  (cr_read (K) J ) ) , 
assert (cr_read (K) ) , 
textOut (act 12) . 

actl3 :  - 
ver (k,K) , 

decision (cr_appr, rev_docl (K) , Doc) , 
assertz (log (approve_cr,  (cr_read(K) ) ,  [Doc] ) ) , 
asserta (Doc) , 
textOut (act 13) . 

/*************  modified  'actRole'  clauses  *******************/ 

actRole (test7in,  act7in,  reviewer,  'start  CR  review'). 
actRole (test7out,  act7out,  reviewer,  'end  CR  review'). 
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Appendix  B  The  Process  Verification  Program 


The  following  is  a  short  example  of  the  output  from  the  verification  program.  As  verification  pro¬ 
ceeds,  the  program  checks  the  validity  of  the  activities  and  consistency  of  their  inputs  and  out¬ 
puts.  When  it  finds  an  inconsistency,  this  inconsistency  is  identified  and  the  program 
terminates.  As  an  example  of  a  process  error,  the  log  statement  below  was  commented  out  of 
the  set  of  log  statements  which  define  the  process  history.  (See  Section  4.1  for  description  of 
log  statements.) 


/*  log (get_f rom_repos_C, [rev_doc_added2 (1) ] , [cr3 (1) ] ) .  */ 

The  resulting  verification  output  looks  like  this: 


*******  review  CR  ********** 

*******  get  CR  from  CR  repos  -  for  review  ********** 

*******  put  CR  revision  into  CR  repos  ********** 

*******  update  CR  ********** 

"get  CR  from  CR  repos  -  for  update"  -  not  performed 

The  following  is  a  listing  for  the  process  verification  program  which  is,  like  the  process  enact¬ 
ment  program,  written  in  Prolog.  While  the  structure  of  the  program  is  similar  to  that  of  the  en¬ 
actment  program  (Appendix  A),  the  verification  program,  as  can  be  seen  in  the  above 
example,  above  is  non-interactive. 


start Verify (FinalEnt) 
initUserVars, 
assert (FinalEnt) , 
verify. 

/**********************  utility  functions  **********************/ 
set (X,I)  : - 

/*  set  the  version  variable  X  to  the  value  I  */ 
retractall (ver (X,_) ) , 
assert (ver (X, I) ) . 

dec (I, J) 

/*  decrement  the  version  variable  I  by  1  */ 
retract (ver (I , J) ) , 

J1  is  J-l, 
assert (ver (I , J1 ) ) . 

del_ent (Store,  Val,  Desc):- 

/*  inverse  of  'put'  -  deletes  entity  from  store,  if  it  is  in  the  store  */ 

/*  otherwise  verification  fails  */ 

testfor_(Val,  Vail), 

retract (store (Store,  Val_list) ) , 

(menber (Vail ,  Val_list) ;  escape (Store,  Vail,  Desc)), 
delete(Vall,  Val_list,  (],  Val_listl) , 
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assert (store (Store,  Val_listl)), 
assert (Val) . 

delete (Vail ,  [Vail  I Val_list ] ,  Val_listA,  X) 

/*  removes  entity  from  list  */ 
delete (Vail,  Val_list,  Val_listA,  X). 

delete (Vail ,  [Val |Val_list] ,  Val_listA,  X) 
delete(Vall,  Val_list,  [Val I Val_listA] , X) . 

delete (_,  [),  Val_list,  Val_list) . 

rem_ent (Store,  Val,  Val2,  Desc) 

/*  inverse  of  'get'  -  tests  if  in  store  then  deletes  retrieved  copy,  if  it  is  in  store  */ 
/*  otherwise  verification  fails  */ 

Val, 

testfor_(Val,  Vail), 
store (Store,  Val_list), 

(member (Vail,  Val_list) ;  escape (Store,  Vail,  Desc)), 
retract (Val) , 
assert (Val2) . 

escape (Store,  Val,  Desc):- 
/*  verification  fails  */ 
write (Val) , 

write ('  is  not  contained  in  '), 
write (Store) , nl , 

write (' Cannot  perform  operation:  '), 
write (Desc),  ni, 

i 

•  # 

abort . 

testfor_(Val,  Vail) 

/*  if  last  char  on  variable  Var  is  an  integer,  remove  it  */ 

/*  this  removes  numbered  extensions  on  products/conditions  */ 

/*  before  they  are  put  into  a  store  */ 

Val  [Name, Var], 

explode (Name,  CharsList) , 
reverse (CharsList ,  [Last  I  List ]) , 
string (Last,  Str)  , 
int2string (Int,  Str), 
integer (Int)  , 
reverse (List,  Listl), 
explode (Namel ,  Listl), 

Vail  -.  .  [Namel,  Var]. 

testfor_ (Val,  Val). 

/*********************  verify  entrance  conditions  ***************************/ 

verify: - 

?  (cr_intern) , 

retract (log (devel_intern_cr,  [intern_prob_iden] ,  [cr_intern] ) ) , 
assert (intern_prob_iden) , 
retract (cr_intern) , 

write  (' *******  develop  internal  change  request  **********•),  nl . 

verify: - 

?  (cr  intern) , 
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not (log (devel_intern_cr,  [intern_prob_iden] ,  [cr_intern] ) ) , 
write (’ "develop  internal  change  request"  -  not  performed' ) >  nl, 
abort . 

verify : - 

? (f ield_cr) , 

retract (log (devel_extern_cr,  [extern_prob_iden] ,  [f ield_cr] ) ) , 
assert (extern_prob_iden) , 
retract (field_cr) , 

write  (' *******  develop  external  change  request  **********•),  nl. 

verify: - 

? (f ield_cr) , 

not (log (devel_ext_cr,  [extern_prob_iden] ,  [field_cr ] ) ) , 
write (' "develop  external  change  request"  -  not  performed'),  nl, 
abort . 

verify: - 

?  (cr_extern) , 

retract  (log  (e-mail_cr,  [field_cr] ,  (cr_extem) ) ) , 
assert (field_cr) , 
retract (cr_extern) , 

write (' *******  mail  external  change  request  **********'),  nl, 
verify. 

verify: - 

? (cr_extern) , 

not  (log  (e-mail_cr,  [field  er]  ,  [cr_extem] )  ) , 

write (' "mail  external  change  request"  -  not  performed'),  nl, 

abort . 

verify : - 
crl  (1) , 

retract (log (format_cr,  [Var] ,  [crl(l)])), 

assert (Var) , 
retract (crl  (1) ) , 

write  (' *******  format  change  request  **********’),  nl  , 
verify. 

verify : - 
crl  (1) , 

not (log (format_cr ,  _,  (crl(l)])), 

write (' "format  change  request"  -  not  performed'),  nl, 
abort . 

verify: - 
ver (k,K) , 
cr_added (K) , 

retract (log (put_into_repos_A,  [crl  (K) ] ,  [cr_added (K) ] ) ) , 
del_ent (cr_repos,  crl (K) ,  'put  CR  revision  into  CR  repos'), 
retract (cr_added (K) ) , 

write  (' *******  put  CR  revision  into  CR  repos  **********•),  nl, 
verify. 

verify: - 
ver (k,K) , 
cr_added (K) , 

not (log (put_into_repos_A,  [crl(K)],  [cr_added (K) ] ) ) , 

write ('"put  CR  revision  into  CR  repos"  -  not  performed'),  nl. 
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abort . 


verify : - 
ver  (k,K) , 
cr2 (K) , 

retract (log (get_from_repoa_A,  [cr_added (K) ] ,  [cr2(K)])), 

/*  tests  if  cr  is  in  DB  then  removes  copy  retrieved  */ 
rem_ent (cr_repos,  cr2 (K) ,  cr_added(K),  'get  CR  from  CR  repos  -  for  review'), 
write (' *******  get  CR  from  CR  repos  -  for  review  **“******’),  nl, 
verify. 

verify: - 
ver  (k,K) , 
cr2  (K) , 

not (log (get_f rom_repos_A,  [cr_added (K) ] ,  [cr2(K)))>, 

write  ("'get  CR  from  CR  repos  -  for  review"  -  not  performed’),  nl, 

abort . 

verify : - 
ver (k,K) , 

(cr_appr,  Var  -  cr_appr;  rev_docl (K) ,  Var  -  rev_docl (K) ) , 
retract (log (review_cr,  [cr2  (K) ] ,  [Var])), 

assert (cr2 (K) ) , 
retract (Var) , 

write (' *******  review  CR  **********'),  nl, 
verify. 

verify: - 
ver (k,K) , 

(cr_appr,  Var  -  cr_appr;  rev_docl (K) ,  Var  -  rev_docl (K) ) , 
not  (log  (review  er,  (cr2  (K)  ] ,  [VarD), 
write (' "review  CR”  -  not  performed* ), nl , 
abort . 

verify: - 
ver (k,K) , 

rev_doc_addedl (K) , 
rev_doc_added2 (K) , 

retract  (log  (put_into_repos_B,  [rev_docl  (K) ) ,  [rev_doc_addedl  (K)  ,rev_doc_added2  (K)  ] ) ) , 
del_ent (rev_doc_repos , rev_docl (K) , 'put  review  doc  into  doc  repos'  ), 
retract (rev_doc_addedl (K) ) , 
retract (rev_doc_added2 (K) ) , 

write  (' *******  put  review  doc  into  doc  repos  **********'),  nl, 
verify . 

verify: - 
ver  (k,K) , 

rev_doc_addedl (K) , 
rev_doc_added2 (K) , 

(not (log (put_into_repos_B,  [rev_docl (K) ] ,  [rev_doc_addedl (K) ,  rev_doc_added2 (K) ] ) ) , 
write(’"put  review  doc  into  doc  repos"  -  not  performed' ) ,nl) , 
abort . 

verify : - 
ver  (k,K) , 
cr3 (K) , 

retract (log (get_f rom_repos_C,  [ rev_doc_added2 (K) ] ,  (cr3(K)])), 

rem_ent (er  repos,  cr3(K),  rev_doc_added2  (K) ,  "get  CR  from  CR  repos  -  for  update”), 
write  ( '****** *  get  CR  from  CR  repos  -  for  update  ***********),  nl. 
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verify. 


verify : - 
ver (k,K) , 
cr3 (K) , 

not  (log (get_f rom_repos_C,  [rev_doc_added2 (K) ) ,  [cr3(K)])>, 

write ('"get  CR  from  CR  repos  -  for  update"  -  not  performed' ) ,nl, 
abort . 

verify: - 
ver  (k,K) , 
rev_doc2 (K) , 

retract (log (get_f rom_repos_B,  [rev_doc_addedl (K) ] ,  [rev_doc2 (K) ) ) ) , 

rem_ent  ( rev_doc_repos ,  rev_doc2  (K)  ,  rev_doc_addedl  (K)  ,  'get  review  doc  from  doc  repos  - 

for  update' ) , 

write  (' *******  get  review  doc  from  doc  repos  -  for  update  **********'),  nl, 
verify. 

verify: - 
ver(k,K) , 
rev_doc2 (K) , 

not (log (get_f rom_repos_B,  [ rev_doc_addedl (K) ] ,  [rev_doc2 (K) ] ) ) , 

write ('"get  review  doc  from  doc  repos  -  for  update"  -  not  performed' ),  nl, 

abort . 

verify : - 
ver (k,K) , 

K1  is  K-l, 
crl (K), 

retract (log (update_cr,  (cr3(Kl),  rev_doc2 (Kl) ] ,  [crl(K)])), 

assert (rev_doc2 (Kl) ) , 

assert (cr3 (Kl ) )  , 

retract (crl (K) )  , 

dec (k, K) , 

write (' *******  update  CR  **********•),  nl, 
verify. 

verify: - 
ver (k, K) , 
crl  (K), 

(not (log(update_cr,  [cr3(Il),  rev_doc2  (II) ] ,  [crl (K) ] ) ) , 
write (  "'update  CR"  -  not  performed' ) ,nl) , 
abort . 

/***********************  initialize  variables  *********************/ 

initUserVars : - 

retractall (crl (_) ) , 
retractall (cr2 (_) )  , 
retractall (cr3 (_) ) , 
retractall (cr_appr)  , 
retractall (cr_added (_) ) , 
retractall (rev_docl (_) )  , 
retractall (rev_doc2 (_) ) , 
retractall (rev_doc_addedl (_) ) , 
retractall (rev_doc_added2 (_) ) , 
retractall (cr_read (_) ) , 
retractall (active (_) ) , 
retractall (intern_prob_iden) , 
retractall (extern_prob_iden) , 
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retractall (field_cr) , 
retractall (cr_intern) , 
retractall (cr_extern) , 
set (k, 2)  . 

crl (0)  . 
cr2 (0)  . 
cr3 (0)  • 
rev_docl (0)  . 
rev_doc2  (0)  . 
rev_doc_addedl  (0)  . 
rev_doc_added2 (0) . 
cr_added(0) . 

/************************  proCess  history  ************************/ 
/*  these  were  generated  by  enacting  the  process  -  see  Appendix  A  */ 

log  (devel_intern__cr, [ intern_prob_iden ] , (cr_intern)) . 

log (format_cr, [cr_intern] , [crl (1) ] ) . 

log (put_into_repos_A, [crl (1)1, [cr_added(l) ] ) . 

log ( get_f  rom_repo  s_A ,  [cr_added(l) ] ,  [cr2 (1)  ] )  . 

log  (review  er, [cr2 (1)1, [rev_docl (1)1). 

log (put_into_repos_B,  [rev_docl (1) ] , 

[ rev_doc_addedl (1) , rev_doc_added2 (1) ] ) . 
log (get_f rom_repos_B, [rev_doc_addedl (1)1, [rev_doc2 (1) ) ) . 
log (get_f rom_repos_C, [ rev_doc_added2 (1)1, [cr3 (1) ) ) . 
log (updatecr, [cr3 (1) , rev_doc2 (1) ] , [crl (2)1). 
log (put_into_repos_A, [crl (2) ] , (cr_added(2) ) )  . 
log (get_from_repos_A, [cr_added(2) ] , [cr2 (2)1). 
log (review_cr, [cr2 (2) ] , [cr_apprl ) . 


store (rev  doc  repos, [rev  doc (1)  ] )  . 
store (cr_repos,  [cr (2) , cr (1)  1 )  . 
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